kapowaz

That’s a pretty big claim. Got a source for it?

Judging from a lot of the serious analysis responses in the comments here, quite a few people.

Interestingly they've built two different versions of the typeface: Compact (for watchOS) and UI (for OS X/iOS). Compact is far closer to DIN or Roboto (with flattened vertical strokes on glyphs like the uppercase C, D and G), whereas UI is far more rounded, and looks a lot like Helvetica for some glyphs.

I was concerned based on what I'd seen of the typography of the Apple Watch that it'd be too cold and characterless (I really dislike Roboto on Android) to use across OS X and iOS, but by creating this separate UI variant they're able to make it feel like a gradual transition from Helvetica Neue. It's so similar, in fact, that I'd not be surprised if we end up seeing more font quizzes asking: ‘Arial or Helvetica …or San Francisco?’

Went to check this — seems that you can watch some HBO shows on instant video, but you have to pay extra for those. Kind of sucks.

I think I can see the intent behind requiring comments be endorsed by ‘users with over 1000’ karma: this is a somewhat arbitrary way of saying ‘users who themselves are good contributors to the community’, but I think that specific way of measuring is naïve.

Using an incrementing value to represent karma means that you can slowly accrue and work your way towards achieving that state of being a good community contributor in principle, whilst in fact still behaving in all the negative ways you are hoping to minimise.

There are quite a few metrics that could be of relevance when looking at people who comment on HN. How often do they reply? Do they post the first comment, or only replies? Do they only reply to controversial subjects? Do they upvote often?

I'd propose that the solution be more subtle. As others have pointed out, you shouldn't implement a system that acts as a positive feedback loop for the most popular topics; that will simply filter out things that aren't in the zeitgeist (and god knows HN doesn't need any more of that).

My suggestion would instead be that all comments are visible immediately, but will be automatically hidden after a period of time, unless they become sufficiently popular. The length of time before they become hidden will depend on the another value, associated with the poster, which would be something akin to the ELO rating system; all users start with the same score, and then that score is modified based on how many people approve of / disapprove of their comments.

Obviously just using these things ignores context, so I'd encourage some more clever introspection of the other things I mentioned above to determine whether they're just posting on a controversial subject (maybe the first reply gets a bonus to the length of time it's visible, or controversial subjects — measured by the frequency of up vs downvotes — don't reduce your personal ELO rating as much).

Of course, these ideas could be equally terrible but I think thought should be given to testing them before committing, and using something more subtle than just slamming the door in the face of people who aren't able to get their comments into the eye line of the HN elite.

Stopped reading Hacker News.

> I would have preferred you used the 90% of your words to give better examples of how to do things better than overstating how OOCSS and BEM are wrong

This is definitely something I'd like to do as well, but I wanted to focus on the areas I found problematic first and foremost. I may post a follow-up based on the feedback I've received.

> Why not have the presentation be the specification, and we can just build the html to conform to the that specification instead

As I said, I don't believe this is an appropriate approach for a medium which has no absolute, definitive interpretation. A website isn't how it looks, because how it looks will differ depending on how you access it. The only absolute truth when talking about websites is the semantic purpose of the markup underlying it, because purpose is universal: a navigation element is a navigation element regardless of whether it's being displayed on a TV, a desktop browser, a smartphone, or being read out by a screen reader.

> I imagine that's just because you'd rather see better looking html than you would see better looking css.

I'm actually interested in both :)

> You have the semantic issues well thought out, however you are flat out declaring data semantics are more important than presentation semantics.

What are ‘presentation semantics’? I think this is a corruption of the concept of semantics. Semantics are what a thing is, or means, or does; not how it is presented

> My CTO and designer (2 people I have a lot of respect for) were the people who eventually changed my mind on this. They said, "I don't know why this button is blue, but it's supposed to be green". Well it turns out it's blue because it has the class blue on it. Instead of trying to figure out what selector was causing this button to be blue, all I had to do was remove the blue class and add the green class. It took 15 seconds.

Changing how you structure the CSS in your application based on the whims of people whose area of expertise isn't CSS sounds like a nightmare scenario to me. If you're bootstrapping with a small team I can understand wanting to have everyone being able to contribute, but you should also be able to recognise what the limitations of their skills are. In the example you give, I would be using my web developer tools / inspector etc. to find out the origin of the erroneous property. If you're using a preprocessor there are source maps that can help with identifying how a rule was built. I certainly wouldn't conclude it's easier to use a presentational class name just so that my CTO could understand the code.

If your CSS ‘impossibly simple’ then it sounds like you don't need it. Every tool has its place: writing HTML by hand is still worthwhile in certain situations. My article assumes you are writing CSS in a project of sufficiently large scale that how you approach architecting it is important enough to think about.

> If I modify one of my building blocks, I know that every instance of it will now look like this.

But that's based on your own system, which may be non-obvious to other developers. The rules of valid HTML dictate the situation in which you will encounter a given ID, so this communicates something to every developer who sees IDs used in a given selector. To me that's tremendously valuable, and far more useful than trying to graft additional meanings onto parts of a single classname.

Whether that system is BEM, OOCSS, SMACSS or some other syntax, this kind of naming convention isn't a native part of CSS.

> No, the primary reason is that IDs prevent reuse.

Reuse of what, exactly? Selectors? Properties? My assertion is that if you need to re-use properties a lot then you should make use of a preprocessor framework and then use a combination of mixins or extends. Re-use of selectors is an unnecessary artefact of how OOCSS (and similar) suggest you should write your code.

> If you want to build a library of reusable components, IDs are obviously not what you want.

If you're building components that could end up on any page entirely outside of your control, I agree. But: horses for courses. It still has valid uses, and avoiding it entirely isn't necessary.

> Secondly, if you use IDs which were added for JavaScript or fragment links, you'll introduce some coupling which really shouldn't be there.

You're looking at this backwards: IDs exist for many purposes, not just CSS. Selecting elements by ID in JavaScript, or using a fragment identifier to link to within a page are just two other examples of how they can be used, and not considering the other purposes of the attribute is part of the problem (see also ‘CSS classes’).

> Same thing with JavaScript. If you need a class, you should add a prefixed one (e.g. "js-foo").

How does the developer benefit from writing the classname like this? Why is a prefixed classname any more informative to you than a selector that tells you a little about the context in which the element appears? I've actually come around to the view that if you're using this class to select on any other criterion than the semantic purpose of the element is wrong, and it would be more appropriate to use a data attribute to contain the hooks for additional behaviour.

> This is non-obvious behaviour that should be avoided.

Generating selectors automatically obviously carries the risk of creating something excessively large that you don't want. But I want to challenge the widely-held view that a long CSS file is necessarily bad. First of all, what does 4,000 lines mean in terms of actual document weight? And what is the weight of the gzipped file actually served? Repetition in selectors might look bad on the surface, but this is exactly the kind of thing that compresses well. Once actually served this file then ought to be cached well, and so the issue of document weight is potentially moot.

Obviously there are extremes beyond which it may no longer be sensible to serve something like this, but arguably at that point you ought to be noticing issues in your un-preprocessed source anyway.

Transposition vs substitution; I'd say F*CK is more likely to suffer the ASA’s wrath than FCUK. But who knows, need more details to be sure of anything.