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.

The mechanic itself isn't actually that interesting. When they released the demo there was a discussion about how the mechanic works over on the destiny.bungie.org forum: http://destiny.bungie.org/forum/index.php?id=15007 — in a nutshell the time pausing mechanic doesn't really make the game a ‘puzzle’: it just lets you pause the game arbitrarily to let you line up your shots. This is why other shooter games (F.E.A.R, Max Payne) that have let you slow down time do so with finite resource mechanics to prevent overuse.

If the developers implemented any more interesting mechanics that let you rewind time, or made some enemies immune from time pausing then this might become an interesting game, but based on the demo it just looks like a shallow but pretty game, and is unlikely to be that much fun.

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.

> what I determined is that there's a new definition of what "semantic" means in front-end architecture. Semantic doesn't just describe the content anymore, it describes the function as well. So using classes like "module-box" or whatever is perfectly fine.

Semantics describes a thing, but classes like ‘module-box’ don't convey any meaning beyond presentation. If you think that ‘module-box’ is semantic, then I have a whole bunch of classnames based on colours to sell you…

> the "separation of concerns" was a good principle to use when the web was a bunch of documents meant to provide content. It isn't that way anymore.

The virtues of this approach have very little to do with the web; it's a concept that pre-dates it, so it's hard to justify it having been invalidated simply by advances in web technology. Besides, a web ‘application’ is equally composed of semantic components just as much as a document is; part of the reason HTML5 came about was to reflect the kind of elements used in modern web pages.

> Using selectors like that (aside from being slow performing) completely tie the markup to the presentation. Hell, if all you did was update the list to an ordered list instead of an unordered one you'd have to update the CSS as well.

This suggests that your workflow starts with CSS and you then build markup to fit it, which his sounds completely backwards to how I approach things. You don't tie your markup to how it is presented: you declare how you want to present the markup your app is built upon. Also, if you change the markup to something with a completely different meaning (an ordered list is meant to have a different purpose than an unordered one) then of course it follows that you'd have to update the CSS, although there's no reason why those changes need be onerous or difficult.

The whole selector performance debate is old and dead, by the way: http://calendar.perfplanet.com/2011/css-selector-performance....

> If you're concerned about the discoverability of the code to a new developer, DOCUMENT IT. Create a UI style guide that implements all of the major UI components and have the developer reference the style guide.

A style guide is a fine starting point regardless of how you want to approach your CSS, but documentation isn't the only way to aid discoverability of code. Selectors that communicate context and purpose can be very helpful for this too.

> 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.

> TfL tried to ban it

Why would TfL specifically get involved? It's more likely this is an issue for the ASA, on account of it appearing to use the word ‘FUCK’, which is hardly controversial.

Being open to abuse and being something that is commercially viable and desirable are totally different things. Yes, you can do all manner of nefarious things with native web technologies — as I understand it, this was one of the reasons it took so long for a native JS fullscreen API to be implemented, as it would open the door to spoofing the operating system's interface chrome.

But where these technologies differ is that Flash was marketed as a one-size-fits-all solution, that allowed designers and developers to work inside of a single framework. The barrier to entry is also very low: you can achieve a lot (relatively speaking) without much technical expertise — certainly when compared to how much effort it might be to do things the right way with native tech.

I don't ever see this happening with the likes of asm.js or WebGL because they're much more narrow in focus, plus they require very different (and non-trivial) skillsets to those of designers. As soon as an endeavour like this requires multiple developers and designers, it no longer appeals to your common or garden ‘chuck it over the wall’ marketing agency; the only ones that can afford to invest in this are the ones using the tools appropriately (or at least, most of them will be).

This is true, but because of completely different toolchains it's very rarely the case that this happens. Flash, at its height, was being used with tools like Flex to build full applications. Adobe provided interface libraries for you to substitute native controls for its own (inferior) versions. Nothing like this exists yet for the tools you mention, and hopefully never will..

> First of all, good old backwards compatibility. There's large codebases still written in Flash, or perhaps things that are in Flash that will never get updated ever again (browser games being a big one), and people would like them to work even after Adobe's dropped out.

It's a fair point that wanting to retain the ability to run this content after there is no (working) Adobe plugin is desirable, but is the browser the best place for this? We don't demand that each version of an operating system is able to run all old application software for that OS; the preferred way of being able to do this is through virtualisation, and I'd argue that's probably a better way to do this, too.

> There has been quite a lot missing from the web standards that Shumway helped pushed through.

…such as? (I'm genuinely interested; I wasn't aware of this)

There may not be any conceptual difference, but there is a very significant difference in how these things you describe are used. Flash, when used badly, becomes a self-contained sandbox for the entire experience of a website. Besides security concerns, this approach is damaging to the overall experience of that site, since developers end up needing to re-implement native controls and functionality (scrollbars, form elements and keyboard navigation to name a few) in order to provide users with affordances they would otherwise take for granted. More often than not, the developer doesn't re-implement these features and so users are left with a sub-optimal experience (even if it is more ‘on brand’, or replete with gratuitous effects and animations). This is to say nothing for the accessibility implications.

Since the advent of smartphones and tablets that can't display Flash content, sites that do this have started to die out in favour of a combination of native applications and true HTML implementations. If the experience they're going for calls for a video or canvas element (3D or otherwise) then great, go for it. But the scope of that part of the experience is implicitly reduced, and so it doesn't result in a sub-par experience across the board (I might not be able to see your fancy WebGL 3D canvas effects, but the links to your ‘contact us’ page still work).

What I'm worried about is that by providing a compatibility path, Flash's imminent demise will be put on hold, and the sub-optimal experiences I described above see a resurgence. And that's not a good thing.

Why do we need this? The way that Flash has diminished in significance since high-quality browsers on smartphones and tablets emerged is a good thing. The web is better with Flash gone completely, not dragged along through compatibility layers.

Nobody ‘decides’; it isn't subjective. If you're discriminating by giving an advantage to a minority when hiring in the interests of boosting the numbers of said minority, then that is positive discrimination. My comment wasn't meant to state any personal opinion of this practice, but to highlight it as being entirely different from choosing to have a work environment in which discrimination (e.g. sexism, as is assumed to be the case with ‘bro-culture’) is not tolerated.

> "bro culture" is bad, but female-friendly (like Minted.com[1]) is assumed to be good. All animals are equal, but some animals are more equal than others.

You're confusing a non-discrimination policy with a positive-discrimination policy.

Why do people keep trying to abstract away the parts of web applications that have been carefully designed to solve that particular part of the problem as best they can with a ‘one size fits all’ solution?

To me the answer is obvious: we have people who don't understand CSS, who don't understand HTML, who do understand JavaScript (or Java, or Ruby, or Go, or whatever) who want to make web applications but have no interest in learning or understanding the reasons why we do things a certain way.

Frankly it depresses the hell out of me for the next generation of web applications, because it feels like we're taking a technological leap backwards.

I wholeheartedly disagree with several of the points you make here, and I think you're more or less ‘passing the buck’ on something which is most definitely your responsibility to take good care with.

On OS X, once you save a password using Safari, it is added to your login keychain. In order to then see that password* you must enter your login password again, be that via Safari's preferences dialog or the Keychain Access application. What Chrome does is it uses the same mechanism of storage as Safari (and indeed, requests access to the same encrypted keychain item) but never prompts the user for the login password to authenticate. This sets up a situation where Chrome actually circumvents and makes passwords originally stored in Safari less secure than they were initially. This is your responsibility, and no amount of theoretical grandstanding about physical access to a computer changes that.

You also talk about installing malicious browser extensions as another potential vector. I agree, and I think browser makers ought to take steps to require the current user to authenticate in order to install browser extensions. When you consider that a browser extension can act as man-in-the-middle to all your browser activity, it's astonishing that this isn't already the case. You have to prove you are the logged-in user when you change your password by providing the current password, so how is this any different?

When talking about security, there will always be holes, but they will be of differing practical value or risk depending on how they are exploited. Grabbing session cookies or internet history requires a certain level of technical proficiency, as does developing a malicious browser extension; installing said extension or typing chrome://settings/password into the address bar, on other hand, are easy enough that any kid who wants to get hold of his big sister's Facebook password can give it a go. Reducing the surface area of attack is every bit as important as ‘real’ security, here, and the stance you've set out above is that you aren't interested in that if it doesn't also provide real security. I think that's the wrong thing to do, and I urge you to reconsider.

*As people have pointed out, you can inspect the password via web inspector etc. This is another, serious security flaw and one that I think the HTML WG ought to look into.

> You don't get to tell Linus what is or isn't professional.

Yeah, he's earned a free pass to be a dick. That's how it works, right?

This seems like a great idea. Build some sort of universal bridge for media keys that any compatible app can hook into? Or would the OS X sandbox prevent that, too?

It could have been worse; his guests could have all had their throats slit in an act of callous revenge (‘The RIAA sends their regards!’).

No.

“The border between the server and the client has faded”

So why continue to use distinct job titles? I think ‘web developer’ suffices; the specific skills you can bring will vary from person to person, but you should be fighting against being pigeon-holed, not embracing it by voluntarily saying you belong in one category and not another.

All very interesting concepts, very nicely implemented. But, I guarantee you Apple has built dozens of designs like this internally, tested them and rejected them because they didn't work as well as what they actually went with.