marahmarie: Sheep go to heaven, goats go to hell (Default)

ETA, 2-22-17: Aaaand killed, rewrote and re-submitted this request, try next one... bingo. (Actually, I'm surprised "Wow, that's weird!" took a whole week to find me. My luck holds as usual).

ETA, 2-28-17: Not weird, just another issue.

  • Move background images from WP to DW (but keep WP backups and WP style sheet, just in case)
  • This layout looks 7 years old and is actually 7 years old; maybe do something about it - ETA, 2-28-17: maybe not? I actually hate doing new code.

Dreamwidth is running a beta of HTTPS Everywhere. This page turns it on; right now it's the second red button down from the top.

I turned it on tonight (actually, just minutes before opening the editor for this post) and have done exactly zero poking or prodding. Since I'm a frequent finder of Wow, that's weird!, if there's any Wow, that's weird! then hopefully my luck will hold. I like finding bugs, as long as they're not destroying things (though, theoretically, I could like a bug that destroyed some or even all the things, but that's probably a pretty far out edge case involving a fake news website of some sort. Thousands to choose from...).

I asked in a DW comm thread and was told by [staff profile] denise that turning on HTTPS Everywhere, the Dreamwidth Beta, won't conflict with keeping HTTPS Everywhere, the browser add-on, enabled while on Dreamwidth, so apparently you'll be able to keep both running at once.

Being me, I'll try the beta both with and without the add-on (I've been using the add-on for a while and am kind of stuck on it - it's not bad as long as you don't force it to run literally "everywhere", which prevents about half the web from appearing in your browser) so I can see how it all gels.

marahmarie: Sheep go to heaven, goats go to hell (Default)

I want these comment sections. If I decide I don't want them in the long run (they are kind of...dull) then I want the easy-to-follow threading (clear indentation with blue side markers - it's like Comment Threading For Dummies!) so, that self, do something like that.

ETA, after posting: maybe change the metadata data to normal font weight, too.

marahmarie: Sheep go to heaven, goats go to hell (Default)


Internet Explorer (all versions) won't support the calc() function. For the longest time I noticed IE11 wouldn't perform @media queries and thought it was IE11's fault for being unable to, but then last week I noticed some versions of Opera (there are soooo many versions of Opera, ya'll) would not perform the queries, either. Suspecting calc() was the issue, I rewrote my calc() functions in longhand and sure enough the @media queries began to work in all supporting browsers, and as a nice bonus, they began working in IE11, too (they've always worked in Edge and - for some reason - IE Win8 Mobile).

I prefer using calc() over setting min, max, and normal widths on page elements and margins because a) it uses easy equations and b) is less code and less calculating because the whole point of it (I think; don't quote me) is to act like an if statement would in JavaScript.


I've always been somewhere between bad and awful at accessibility but I'm working on getting better at it. While I've slowly made a lot of concessions changes over the years to make things more accessible, I still had (have, if you count all the crap hiding in @media queries) a lot of stuff hidden in display: none. This is bad. So is text-indent. So is height: 0; width: 0. So what's a girl to do, huh?

The best all-in-one-answer seems to be this combination of rules. The link title misleads one into thinking the article covers only the use of clip: rect() but it actually covers best practices and explains why other practices are not the best. With the obvious caveat that people like Chris Coyier keep saying about the use of clip: rect(): 'but it's DEPRECATED so don't'. But here's the thing: no one cares if it's deprecated or dead and buried as long as it works. And it does. Browsers still use it while clip-path: inset() doesn't have full cross-browser support yet (not to mention clip-path: inset() has zero backward compatibility; clip: rect() works without the comma delimiters in use today in IE6-8).

Background Images

I have a total love-hate relationship with background images being used in design. If anyone thinks the design I'm currently using is image-heavy (I wouldn't blame you, but) visit [personal profile] style_test, which shows a legacy copy of this design in its original, untouched form. You won't see a single image on it because I never uploaded them to Dreamwidth (I think I still have them on an external hard drive, somewhere) but if you read the CSS you'll see it's like wow, have some text with your images. I used it that way for at least four years before finally hoovering some of them out.

I could go on and on about how many of those images I think are extraneous (technically all of them, besides the main background) but I have to concede I thought the layout looked incomplete as-is (yes, with not enough images!) so I added the entry title, comment title, sidebar title and header linkbar images years ago (if I recall right, the sidebar images are from Michael Tyson's design and the entry/comment images are from an early prototype of Elegant Grunge from so long ago it wasn't even called Elegant Grunge yet, which is another reason I love

But for the short list of "too many images in the original CSS"? There are two fullscreen headers and footers. Every last link except those in .entry-content and sidebar .module-content has images. Yet the entry content is less than 300px wide (because anything bigger would break in IE6, which the design was made to work in) so when put together as intended, all you see is images. It used to make my head swim. But I thought it was "modern design", so for the longest time I stuck with it.

Then Microsoft spearheaded flat design with Win7 Mobile. At the time I thought I should use aspects of "modern design" like drop shadows, text-shadows, rotated images and shiny everything - I mean, images had to literally *shine*. I still have a copy of my layout from back then and sometimes I run it side-by-side with today's and just laugh and laugh and laugh. MS might not be good for much but flat design was the best thing that's happened to me anybody and they really made the first big push on that. It's less image-load, less server-load, less CSS, and I think it's easier on the eyes.

That aside, I never thought of using even less background images until [personal profile] pulchritude ran into problems a few years back with how things looked without them. She uses a proxy and has to disable images so this was bound to be A Thing. Since then it's hit me that my online acquaintance is not the only person surfing via imageless proxy, so I've been reducing images and trying to get a bit closer to pixel-based design ever since.

CSS as a logical system

I plan on doing nothing online this year except learning more about how CSS3 and HTML5 do the things they do. As mentioned in other posts, I think both technologies can (and eventually should, so dear IEOld: please die, already) replace JavaScript and a host of other backend functionality. The only problem, of course, is while non-programmers like me don't care if CSS and HTML are as logical (or as strictly "programmable") as most backend programming languages are as long as they do what we want, programmers care a lot, because lack of logic impedes usefulness.

In trying to find an answer, I came across Logic In CSS, which suggests CSS is plenty logical as-is. That led me down a rabbit hole where I learned there's a push on for OOCSS (Object Oriented CSS) because CSS can already be abstracted to save time and many lines of code (think LESS and SASS). All properties|values food for thought.

marahmarie: Sheep go to heaven, goats go to hell (Default)

Update, 9-21-14: added new Support request URL.

I just noticed your Dreamwidth login gets passed to so* (see correction below) the emulator winds up displaying all of your locked entries. I am kind of freaked out about this so I have a Support request in with DW to check if a) it's normal for emulators to get passed our log-in info to be able to display our locked entries and b) to find out if DW staff feels this is a security risk.

I feel it is a security risk - regardless of how they feel about it (no offense intended but oh, happy hell) so until someone can explain to me how it is not a security risk, my question - and my sheer anxiety over it- will stand.

*Correction: as pointed out by [personal profile] ideological_cuddle in this thread, I've worded this issue quite badly from the start. I don't, in fact, believe our log-in state is passed directly to; rather, I'm questioning whether our logged-in materials are (as he explained, these materials are presented in an IFRAME, allowing even our access-only posts to display in their emulator if we're already logged into DW).

Given this refinement of exactly what I feel is the potential security risk my question stands, with the caveat that I'm not worried so much that our log-in details (such as username and password combos) are getting passed along as I am that our access-only content is first getting displayed in's IFRAMES and then somehow being scraped and/or stored by them for future use/disbursement.

Sorry for my original wording; on account of it I'm leaving it as-is with strikethroughs added as needed to show where I really confused the hell out of exactly what I'm on about here.

marahmarie: Sheep go to heaven, goats go to hell (Default)

The thing is, if you disable your favorite browser's default styles (I use Firefox with the Web Developer add-on to do this under CSS-->Disable Styles-->Disable Default Browser Styles), then check your style sheet's display for inconsistencies and correct them as needed (I use resource://gre-resources/html.css and resource://gre-resources/forms.css to see what's going on) then haven't you effectively coded your CSS to work with the default styles of any modern browser? Because with that one browser's defaults disabled you're effectively coding with no default styles enabled for any browser at all, so you're forcing yourself to write bulletproof code without performing any cross-browser checks beforehand.

For added bulletproofedness you can use Web Dev to check Box Model compliance (Web Dev - CSS-->Use Border Box Model) - an exercise in torture for me because my entire blog narrows when I do that, but it's helped me solve two or three otherwise elusive bugs ETA: fixed; needed to remove padding from #wrap.

So no need to zero out everything and its brother before you start styling, no need to perform a reset, and no need for endless cross-browser checking. And before you whisper "IE OLD" at me, forget it. No browser designed to work in Quirks Mode to this day for backward support of websites made when IE1 was still popular should count for much unless you really care that slightly more than 50% of the population still uses some version of it (over 30% use IE8 on Vista, if you really must know, and yes...Vista, seriously). Besides which, anything at or above IE9 should work with what I'm suggesting.

For more bulletproofedness you can make sure your DOC type supports Standards, and for the most bulletproofedness possible you can make IE use IE Edge so when someone goes to click the Compatibility View button, it's greyed out and completely disabled, with no workaround to bring it back unless they use IE's built-in (and in my personal experience, quite hellish) Dev Tools.

In fairness to the zero-out-and-reset-it-all crowd, the main benefit of doing one or both is it might allow you to use less code overall; less code means smaller style sheets, and smaller style sheets mean faster page loads (and I want every page to load, at most, in a billionth of a second if it must take that long, so this is an Objective, for sure). If you zero out line heights you can set one line height on body and be done with it; margins and padding might work the same way depending on what you hope to accomplish and how good you are at pulling it off without adding an entire rat's nest of code to your style sheet.

Or if you don't want your code all that bulletproof? Your webpages don't have to look the same in every browser, anyway, so why bother? If it were up to me I'd have an unstyled, utterly resizable page for mobile and a much simpler design for IE - I have zero desire to be matchy-matchy across all the many browsers out there today. I simply want my code to work (and work as intended), wherever someone might see it.

marahmarie: Sheep go to heaven, goats go to hell (Default)

It's been working on me lately so with Thanksgiving coming up I have to say it: while I am thankful for the fact that I can write my own CSS, control and change my own and other's website designs (even Google's), create my own userscripts, and put my post images between properly formatted HTML div tags, I have a troll from my more intensely Anti-AOL days to thank for all of that.

No, he never taught me to do a damn thing. He simply made fun of me for not being able to. Along with calling me a bitch, a slut, a whore, and several other unsavory slurs; he was a sexist, a monster, a troll, an AOL employee, a complete PITA, and would not go away for so long I actually contacted the president of AOL in my one weak attempt to get him fired, but his IP was of course untraceable, just leading back to one of AOL's many server farms, and his name was totally unknown. He worked in unison with a lesser troll, whom I eventually shook down for a name - to no avail.

I finally starved him to death - at least emotionally - by screening his comments and refusing to reply no matter what...I mean, once in a while, once I got over the initial shock of it, I might've actually throw in with, "Go on, go on, I'm all ears" and just let him go, but other than that I simply ignored him. It took less than a week for his vitriol to finally die off, or for him to grow bored with talking to himself about me - I'll never know which one for sure - and I've almost never left comments unscreened on any blog of mine since then (if I do I make sure to watch carefully lest he or anyone like that ever intrude again).

His abusiveness, while deeply shocking at the time, is something I've since come to terms with. I think, at times, many of us run off at the mouth and say things we later regret, or, if we don't regret our mean spirit in itself, we regret that we bothered expressing it, that we wasted our time...this is part of the human condition, and a facet of it I can cop to more than I'd like to admit. Not to say that I sympathize with my troll, but frustration can unbelievably warp a personality, and I believe that the fact my blog existed in and of itself frustrated him exceptionally. My blog was the outward sign of everything wrong within his industry, and I wound up bearing the brunt of his hatred for that.

Like almost anyone, even my troll had a personality and chose to express it in some occasionally LOL-funny ways (you had to be there but trust me, outside of one guy named Mike - whom I copied all his hate speech to so we could cluck over it each night - you weren't). He picked on me for using centered paragraph tags instead of centered divs. He picked on me for using pre-rolled LJ designs....and bad ones at that, in his almighty opinion. He picked on me for not knowing how to write my own CSS. He picked on me for being too good at SEO while not knowing how to write at all, and while that is a valid criticism, I still can't do anything about it.

When all the hullabaloo finally died down and I was left, blissfully, with nothing but my thoughts to mull over, I realized that as vitriol-packed and dismissible as most of his criticisms were (sticks and stones, really) the part about not knowing how to properly format my posts and design my own blog had stung me to my core. So, long story short? I started learning, though I'm nowhere near done.

So if you've ever liked anything I've put together online from a design perspective, thank me if you want - but this Thanksgiving, you can also thank a troll.