
pixel skylines
$LAYYYTER

blake kathryn
wallacepolsom
Lint Roller? I Barely Know Her
trying on a metaphor
cherry valley forever
Peter Solarz
Stranger Things
🪼
Claire Keane

roma★
macklin celebrini has autism

⁂
Three Goblin Art
we're not kids anymore.

if i look back, i am lost
hello vonnie

Andulka
AnasAbdin
seen from United States

seen from United States
seen from Japan
seen from United States
seen from United States
seen from Argentina

seen from United States
seen from United States
seen from Malaysia

seen from Malaysia

seen from Indonesia
seen from Germany
seen from United States
seen from United States
seen from United States

seen from Japan
seen from United States

seen from Germany
seen from Angola

seen from United States
@mrwebpage
We've been talking about this at work today. Looks really sweet for doing html emails in django.
You write good html specifying css classes, it outputs ugly but email friendly inline css. A nice way to keep your email templates DRY. If you've ever worked on html emails, you don't need any more convincing.
In this particular (and rare) circumstance [of large websites with lots of legacy CSS], where dueling developers have added rule after rule to a huge, shapeless style sheet that is more of an archeological artifact than a reasonable example of modern code, Nicole’s admonition to avoid descendant selectors based on id is probably wise.
In response to: In Defense of Descendant Selectors and ID Elements – Jeffrey Zeldman Presents The Daily Report
Rare? RARE? What kind of dinky little disposable sites does Zeldman work on? I can't take anything that he says at face value, because I just don't work on the kinds of projects he works on. I've never worked on a serious project that didn't have tons of jumbled css.
Also, is it just me, or do his arguments for ids just not make any sense? How is an id "more semantic" than a class name? #footer and .footer both say footer. What's more meaningful about # than . ?
Saying you just need a master chef and permission to do some refactoring shows a lack of understanding of two things.
One. Refactoring CSS is hard. When it's not compartmentalized in the manner of OOCSS or SMACSS it's really, really hard. Because it's all one jumble and you have to test everything on every change.
Two. A master chef would have to have absolute control over all html and css. I mean code review every checkin and make every dev do things the 'right' way. But if there's no system of compartmentalization, then every contributor has to have just as much knowledge and comprehension as the master chef. That's totally untenable. Each dev needs to write 'good' CSS on their own, or you'll have to correct them every time.
So, those are the two main problems that OOCSS and SMACSS try to solve. In that context, I don't think Zeldman's arguments are very relevant.
(via Your CSS is a Mess // Speaker Deck)
I wonder if embedding works for slide decks.
To combat this font-sizing problem, we now have access to the rem (root em) unit. This is still a relative unit, but it’s always relative to a fixed base value, which is the font size of the root element of the document (in HTML, that’s always the html element).
A List Apart: Articles: Learning to Love the Boring Bits of CSS
Also, calc()!!! *swoons*
HAAAWWWT!
Not everything always works in your favor when you design for the screen. Interaction design is engineering: it’s not about finding the perfect design, it’s finding the best compromise.
Responsive Typography: The Basics | Information Architects (via)
This actually even works in IE... 7! IE7!
Here's at least one credible sounding vote for "put the css in the head and call it done."
After reading this, you won't be able to point to your hand built, client side css loader to prove how clever you are. But you will be able to point to your lack of hand built, client side css loader to prove how clever you are. So that's something.
Pretty good comparison between SMACSS and OOCSS.
I've tried out OOCSS a couple times and it's not an obvious win. It's hard to get right. I'd like to try a project using the SMACSS approach. I think it might be easier just because the docs are clearer.
Using ID selectors To be clear, using ID attributes in your HTML can be a good thing and in some cases, absolutely necessary. For example, they provide efficient hooks for JavaScript. For CSS, however, ID selectors aren’t necessary as the performance difference between ID and class selectors is nearly non-existent and can make styling more complicated due to increasing specificity
Book - Scalable and Modular Architecture for CSS (via DN)
I've tried it. It can make your type pretty.
Looks cool. has anybody tried it? (via Handlebars.js: Minimal Templating on Steroids)
Cutting the mustard
The browser is a hostile development environment and supporting a wide range of desktop browsers can be tough work.
One of the immediate challenges we discovered when we first started the responsive news prototype was the large range of devices that we would have to support. It terrified us. This article is about a solution we use to alleviate this problem.
Read More
hg update
After spending the last 7 or so years in subversion, the switch to mercurial is non-trivial. There's a lot to un-learn (I still type svn sometimes).
All the books and tutorials that I've read keep making these claims about how mercurial is so easy. Mother-uckers doth protest too much. Sure, the syntax is nice and coherent. But conceptually, in a team environment, mercurial is way more complicated.
In "traditional" client/server version tracking systems, you have exactly two things to think about. Your working copy, and the server's definitive copy. 2. It's a nice small number. Easy to think about.
In distributed systems like mercurial, there is no server, except when there is, but it's just one more copy. I say one more, because the preferred method of working on stuff seems to be making local copies of the repository. Like, lots of them.
So you end up with a bunch of repositories that are similar. They are technically unrelated, but they're kind of related. So there ends up being a graph of relationships between repositories. They are easy to merge back together, because mercurial is good at merging. But repo-relationship graph just exists in your head, as far as I can tell*. This is the part that's throwing me the most.
The concepts do have a lot of power, I can see that. I'm just frustrated that it's been 4 days and I'm not the god Mercury yet. I'll get there eventually.
* when you clone, mercurial keeps track of where you cloned from. But I'm not sure how I would know that without looking in mercurial's private .hg directory.
Make things as semantic as possible, but no semanticer.
Mr. Webpage.