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?’

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.

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.

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.

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.

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.

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.

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.

Comments URL: https://news.ycombinator.com/item?id=6584628

Points: 59

# Comments: 43

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.

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

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)

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.