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

ETA, 4-23-17: Swapped to gendered pronouns upon request, clarified [personal profile] solarbird's changes to the navbar were live CSS edits, not "mock-ups", fixed broken navbar section for Firefox on Mac (for all changes please see comments).

So except for mostly minor "fix it as we go along" stuff, I've not seriously updated my CSS in over a year, which I know because the last time I went through my code I didn't live here. :)

Though I've wrangled with the idea of switching up the layout, I've adapted Craigslist's attitude of, "If it's not broke, don't fix it" along with, "Anything we want can be added, so why change the whole damn thing", which means yes, this page will probably remain in the aughts forever, because Craigslist is right.

In the meantime I was busy never editing my CSS again when I ran across a new suggestion for adding a drop-down to the top navbar's Inbox, which by itself didn't cause me to edit or change anything. But then [personal profile] solarbird, the suggestion author, began talking about changing the top navbar in general, pointing out what I'd been too kind to mention when I commented: that it needs to get hit by a car a serious update for modern, non-table-based times (it's all tables. Tables, tables and tables. All taaaaabbbbbbllllles. Even those of us who come from LJ (all tables, until Russia took over) can have a hard time with tables. I learned to make web pages one way: in CSS. Not tables).

After mentioning she'd love for the text to at least align on it (simple enough, right? Y'all wouldn't believe how hard it is) I gave her most of my navbar code, which was nothing and looked something like this, which is from a much older style sheet.

Of course, I can't share my code without wondering what inspired me, because I hate everything I code, so I started picking my navbar CSS apart based on some of the things [personal profile] solarbird wanted, then compared what I had to what she later posted pictures of after adding the CSS to her DW. The code knocked mine clean out of the water, so then I guess I had to make a better navbar - if only for myself - because I'm not going to admit I'm kind of competitive, because I'm totally, absolutely not anything like that and anyone who thinks so is delusional.

Comment exchange went on as Denise more or less tried to hire [personal profile] solarbird right from the web page (she's a designer, from what I gather) before I decided to tear my navbar code apart and re-write it; hopefully the end result is better than what it was. It wraps on mobile based on back-end code put in place by DW; while I'm not happy with the wrap (it collapses to one column while there's still room for two; I keep my wrapping parameters somewhat tighter) it's relatively fail-safe, which is why I don't change it.

So I kept a few lines of my original navbar edits and just started over: even my last update to [personal profile] solarbird is obsolete because like anything else, I'll edit until I just can't stand to anymore.

Now what we have is:

  • new navbar background
  • better navbar text alignment
  • navbar font-size increase
  • navbar "search for interests" text field (it needs a label - some forgotten code elsewhere in my style sheet had kept this text field hidden altogether)


The navbar, though you wouldn't know it, has three sections: 1) user/user links, 2) name of journal you're viewing/related links, 3) interest search and reload page: light|original. While my thought was to spread those sections out more evenly, there's too much whitespace, so I simply spread them out more than they were.

Parallax scrolling: I've wanted it forever so now I have it - but only in (logged-in view) Firefox; in Webkit/Edge/IE and logged-out Fx it falls over (or, more precisely, falls under the header about 10-15px, where it stays until it goes away altogether on smaller mobile views) so after hours of fiddling, finally I was like "the heck with it" and set three views for the navbar. Yes, three, all at once:

In logged-in Firefox it's set to parallax (position:fixed); in Webkit/logged-out Fx it's sticky (position:sticky - still in experimental W3C status) and in IE10/11/Edge it's set to normal (position:relative). Parallax *almost* works in Edge, except same as Webkit/logged-out FX, I can't get the navbar to stay behind the header until your first downward scroll completes.

Since I was in the CSS editor, anyhow, I fixed maybe half a dozen funky little things - like the username and usericon on edit comment forms floating around in the middle of them like, "Huh? Where am I?" That's been an issue for years, and for some reason it was finally starting to drive me nuts.

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

Itsa coming. Saying so because while I don't like to admit suggestions I filed 3,000 years ago still mean something to me, they do, and I was just looking at my Tags page, and holy Mother of God, I don't even know what's on it.

Mainly, I need a way to target locked posts and a way to style other effluvia that helps me get/keep things straight - neither idea is getting implemented beyond what we already have, but at least I can fix views on some other stuff - the tag count in the sidebar and comment counts on the Month page, which admittedly are more aesthetic than practical issues.

Right now I'm trying (and failing O_o) to find a post about eBay made around Christmastime; it's not under my eBay tag but should be. If I had a way to parse protected posts from public posts (it's protected) that would narrow it down a bit. And while technically there *is* a way (there's some CSS I can pull and target; I've done so in the past but don't even think I own a copy of that version of this style anymore) it's limited in scope because so many of my tags encompass both public and protected posts that there's no way for the CSS to target one or the other - so no, the CSS can't say: "Tada, here are only locked posts made under this tag."

Which is exactly what I need it to do, and doesn't seem like an unreasonable thing for it to do, but probably requires so many orders of magnitude of rewriting the backend tag publishing system that it's not worth doing (and while I don't think I can prove it as I don't know if I kept a local copy of this suggestion, I'm pretty much 100% sure I've suggested this functionality in the past).

The changes rolling out won't address that, but I almost don't care, as the CSS I can currently target will still say: "There has ever been a locked post under this tag"; it just takes longer to trawl through the results, as public posts will still be mixed in with protected (because the CSS will always, if I recall correctly, default to targeting the pseudo selector for any protected posts that fall under each tag).

ETA, next night: and that's fine and well, but the logic for deciding which tags get the public or protected parameter looks like it tends toward "whatever parameter has the most posts is Winner Takes All", which means a majority of my locked posts won't show up merely by exposing whatever tags do get the visibility protected selector assigned to them. In fact, adding such CSS would be equivalent to hiding even more posts on myself than I do now simply by mis-tagging or forgetting to tag.

But that means finding and targeting the exact CSS again, then adding it to my style sheet and updating it - I mean, to find one freaking post (there are probably others, which is why I find myself bitching about Tag page CSS in general - I know I'll have to go back and find and re-tag more stuff, not to mention change some posts from protected to public, as I accidentally forget to change the access level on more of them than I care to admit).

It would just be so nice to have a way to sort out public posts from protected ones, as that's sort of an informal filing system in itself - at least for me.

ETA2: just checked Archive Year and Month: Year doesn't parse public from protected posts via CSS, while Month shows a lock next to each protected post, so I'm not sure what else it would need - if anything - to make it more useful. (Maybe unhiding tags on that page would help - will try that next to see what can be manipulated, if anything).

ETA2a: Month doesn't parse between public and protected filters, it just slaps an .access-filter selector on anything not public, which wheeee, why don't we have standardization across our CSS, I think that kind of bugs me. Unfortunately (if you're looking to hack in some sort of workaround) the CSS is semantic, so there's no sneaking in say, dt .access-filter + tag {do this:now} and making it work. I can target surrounding CSS, but that just changes all instances of it on the page without targeting merely the protected tags I'm after.

ETA3: [personal profile] brainwane points out a few ways to parse public from protected posts, namely by using URL parameters like so: "" or choosing from a list of parameters:

If you try a value for "security" that doesn't exist, like "custom", e.g.,

you get a list:

"You can filter entries by the following security level:

Public [link]
Access List [link]
Private [link]

[personal profile] darkoshi adds that you can combine tag names and security parameters like so: "". The page they saw that on also has this suggestion from [personal profile] chagrined:

you can already search for two tags at a time also but I'm on my phone and don't remember the syntax for that ottomh, I can look it up l8r if u want. I think it is limited to only 2 right now tho. but still handy.

eta: nm found it in faq it's tag/tag1name,tag2name?mode=MODE

and where I wrote MODE put either "or" or "and" (and gives only posts with both tags)

iirc can stack with security level filtering too I think


All of these tricks are lovely and useful, but not what I want. I'm just looking for a way to parse - in particular - what's public from what's private without having to scroll through pages of posts found under each tag. Lists of posts found under each tag, sorted by public or protected parameters, would be better - an internal, non-public way to get search results for my posts, in other words, in simple list form, with dates besides the posts under each security parameter in question to help determine which is the lost post (or posts) I'm after.

Basically, I want a system so simple it works for people suffering from memory loss. I'm not claiming that might be me, but there are days it feels like it.

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.