blog.kaelig.fr
That's kind of the whole idea.
It's supposed to help to not mess other parts of the page when they change something.
Their page design is not supposed to be overall consistent and re-usable. They are supposed to be able to do long or surgical changes to any individual section at whim, without affecting anything else -- having sections with a unique new look weeks before updating anything else, or creating special purpose looks for different sections.
For this purposes, reusability and less nesting would be a nightmare.
Nesting (especially this deep) is usually a bad idea. Have you heard of BEM? This methodology helps building reusable modules without polluting the global scope.
Of course the simple explanation can be: write everything, everywhere. But I'd love to hear some expert insights from people who have to think about not breaking these things all day.
I ask, because they are distracting and shred any seriousness laid out in the article. Some of these articles are rich in content, but reading them at work with flashing/animated nonsense feels like I am viewing Reddit to people passing by.
It seems to be tapering off lately, but it used to irk me greatly when a technical blog article would have a bunch of random photos stitched in that had absolutely nothing to do with the content.
http://www.ifixit.com/Teardown/MacBook+Pro+15-Inch+Retina+Di...
Similarly, the filesystem on OS X. As far at the Mac parts go, while the BSD folders have visibility toggled off.
All I did say is that they absolutely do _care_ about what's below the surface. Parts that a fraction of a fraction of folks will ever see are given loving attention far beyond the norm. Do most or any other manufacturers color coordinate battery warning labels, PCBs, etc., down to the cm^2 headphone jack?
iOS's WiFi still hasn't fixed the basic usability bugs I reported against 1.0 (simple things like “Don't capture the UI until the hotspot page has actually loaded” or “Don't nag me asking to reconnect to a marginal network I already requested you connect to”).
iOS autocomplete remains an embarrassment, frequently turning correct words into nonsense or failing to handle minor inconsistencies in input which didn't produce a valid word.
iOS backups don't backup the stuff you care about like passwords or settings but do backup things you can trivially re-download from the store like apps. This is not in any way documented and the backup status will simply claim the backup was successful without mentioning that it includes almost nothing important.
FileVault had data-loss bugs for multiple releases until v2 was released. Time Machine still doesn't check data integrity and the remaining users complain about weird UI bugs, performance impact, hangs & data loss, etc. Nobody at Apple appears to care.
iCloud sync is a disaster with uncontrollable delays and hangs (e.g. http://createlivelove.com/246). There's no sign of anyone at Apple caring since it hasn't impacted iPhone/iPad sales.
To reiterate: Apple doesn't obsess about quality unless it's needed to get people to buy the device.
It's really a big accessibility problem. I can't read this article without using the Chrome inspector to change styles.
And I'm far from being visually Impaired.
Sorry, but it must be said.
I'm guessing English isn't your native language, so this is a diction note:
You should say "I've been wanting to fix". "willing" is strictly correct, but it conveys that you've been waiting for someone to ask you to fix it. "wanting" conveys that you knew about the problem but hadn't found the time to deal with it.
Hope that helps.
(Also, before saying that I've written this out of some foreign notion of English and that I just wouldn't understand, my own native language is English.)
(though I'm not averse to using awkward phrasings or the like in casual situations where clear communication isn't the number one priority. At the moment I'm on a crusade to bring back "thrice" and {h,th,wh}{ence,ither}. )
Let's hope these hundreds of devs don't look too closely. Referencing 11+ seperate JS files in <head>, among them unminified libraries, isn't exactly best practice. They violated all the rules:
1) Combine! 1 CSS + 1 JS are usually enough.
2) Move JS to the bottom if possible!
3) Minify!
(I'm talking about www.apple.com, not the store.)
I'm starting to wonder about using checklists for deployment (yes, your deployment should be automated. You still have to go through the checklist at least once). There are lots of them out there, but they seem pretty pretty general, mostly. There are also a lot that are internal to a given company, used for a specific application.
It seems like there should be an intermediate level, though. Just like any OSS project is expected to have a readme and a changelog, it should also have a CHECKLIST.txt. Drop it into your checklists directory (or have a script that collects them for you) when you add a library to your project, and go through them all before releasing.
Things that Apple's customers don't care about at all include: The code. Or whether or not that code "smells".
This would be an interesting story if it spoke in terms of something important. "Here is how Apple could probably boost sales by 0.1% by optimizing their SaSS" would be a good story. "Here is how to make the Apple Store load 25% faster by optimizing its SaSS" would be a good story.
But "here is how Apple could make their SaSS more aesthetically satisfying to the 0% of visitors who will pay more to read higher-quality code in the Web Inspector" is, at best, an academic exercise.
Production code exists to solve problems, and its quality is not merely a function of the code itself, but of the time constraints, the budgetary constraints, and the magnitude and urgency of the business opportunities. How many millions of dollars of product did Apple's "bad" SaSS sell in the time it took to critique it?
Apple is preaching engineering excellence through their campaigns and products. In the Apple World, the quality of a product is not something you assess only depending on the money it makes.
If one of their developers is reading this I am happy to help with Sass architecture and best practices.
Your use case is not Apple's use case.
They're not designing Flickr, some blogging service or some news site.
The smells are there for a reason. The pages and styles are not to be reusable -- they are meant to be easily replaceable on a per page / section basis.
What reason is there for CSS that is commented out? Or for redundant prefixes? Or for debug to be left on and to have a bunch of comments and paths from the build structure?
So you can debug problems being seen only in the production version?
Only if you have measured both, and found that minifying makes a difference on the scale you care about. Which might very well NOT be the case with Apple's site.
They have tons of images, a lot of them very high quality and size (even retina). So a difference of a few K in the CSS would not even register in the assets transfer time. E.g you should now sweat 10K vs 20K CSS, when you have 2MB of images to serve in the same page.
Oh, and it would only matter if they are not transferring assets as gzip in the first place -- in which case minifying is mostly redundant.
Right now we're only using it for our upcoming signup/login redesign, but it's available for use elsewhere and will probably start popping up on other interaces. We debated whether to even include the Sass files and associated errata at all though, to be honest.
Also: it's Sass, not SASS.
I also added a link to the Sass website in the first part of the post.