Entry tags:
Coexistence Alpha: a responsive mobile and desktop overlay for Dreamwidth
UPDATE 2018/12/4: QUESTION 1: Yes, this respects your colours; I just like green.
UPDATE 2019/2/6: QUESTION 2: Yes, this sat fallow for a while, but no longer. We have a second RC.
You Want Mobile Dreamwidth, Artie? You Got It.
Coexistence Alpha: a mobile-friendly CSS patchset for Neutral Good - v0.846 RELEASE CANDIDATE TWO
(2019/2/6)
This is a fully-responsive mobile-ready theme modification layer intended to make Dreamwidth's default style fully functional on both mobile and desktop devices wherever it can be applied. Features include journal and reading pages with near-zero horizon scrolling on mobile, including in long comment reply cascades, and more-comfortable comment creation, including on iOS.
To install: Choose style "Neutral Good" for "Practicality" in the journal style selector. Copypasta all of the linked CSS into the Advanced Seettings Custom CSS box, and save. (This may require a desktop device.) Apply "your style" to everything you can.
This build includes Navbar 2, which is mostly cosmetic but somewhat mobile-aware upgrade of the Navbar.
0.846rc2: issues with proto-emoji/"subject icon" functionality triggering horizontal scrolling.
0.845alpha: issues with external image size limits (to prevent horizontal scrolling) fixed.
0.844alpha: issues with qrform select box placement.
0.843alpha: some divs in RSS feeds disallow whitespace wrap, causing horizontal scrolling. I'm as surprised as you. Overridden.
0.842beta: Small calendar module cleanup on desktop views. No bugs externally reported, last three builds. We are now in beta.
0.841alpha: Previous N/Next N links given more height.
0.840alpha: Cleaned up code a lot, particularly comment handling on mobile, which gives you even more text entry room now.
0.834alpha: Individual-comment reply form (reached via inbox reply) cleanup. Small Navbar 2 button regularisation on Reading page view.
0.833alpha: Fixes a small border problem, alignment issue on Reading page.
0.832alpha: Rebuilds Navbar 2 from the top down, and adds some mobile awareness, again mostly cosmetic, but hopefully a bit more visual coherence nonetheless.
0.830alpha: Hands body font size back to user preferences, removing the hardcoded size used until now. The system default is 1em. This unit (em) is unreliable across browsers; I have changed my body type size to 14px and recommend the use of a px-based size generally.
solarbird_testbed is always running the bleeding edge build or later (when code changes are in progress).
.82x fixes included Navbar 2 working better on Android browsers (Login panel is still a bit of a mess but I don't care, all that's going away in Navbar 3 anyway), comment thread depth indicators on mobile working even without subject lines, various overprint issues, and so on.
.81x fixes included user left-right selection of icon placement is honoured correctly again. As are icon sizes except on mobile comments where you're forced to "smallest" regardless. Also, the implementation was improved.
And if you see issues, please give me a screenshot and tell me your browser and OS. Thanks!
UPDATE 2019/2/6: QUESTION 2: Yes, this sat fallow for a while, but no longer. We have a second RC.
Coexistence Alpha: a mobile-friendly CSS patchset for Neutral Good - v0.846 RELEASE CANDIDATE TWO
(2019/2/6)
This is a fully-responsive mobile-ready theme modification layer intended to make Dreamwidth's default style fully functional on both mobile and desktop devices wherever it can be applied. Features include journal and reading pages with near-zero horizon scrolling on mobile, including in long comment reply cascades, and more-comfortable comment creation, including on iOS.
To install: Choose style "Neutral Good" for "Practicality" in the journal style selector. Copypasta all of the linked CSS into the Advanced Seettings Custom CSS box, and save. (This may require a desktop device.) Apply "your style" to everything you can.
This build includes Navbar 2, which is mostly cosmetic but somewhat mobile-aware upgrade of the Navbar.
0.846rc2: issues with proto-emoji/"subject icon" functionality triggering horizontal scrolling.
0.845alpha: issues with external image size limits (to prevent horizontal scrolling) fixed.
0.844alpha: issues with qrform select box placement.
0.843alpha: some divs in RSS feeds disallow whitespace wrap, causing horizontal scrolling. I'm as surprised as you. Overridden.
0.842beta: Small calendar module cleanup on desktop views. No bugs externally reported, last three builds. We are now in beta.
0.841alpha: Previous N/Next N links given more height.
0.840alpha: Cleaned up code a lot, particularly comment handling on mobile, which gives you even more text entry room now.
0.834alpha: Individual-comment reply form (reached via inbox reply) cleanup. Small Navbar 2 button regularisation on Reading page view.
0.833alpha: Fixes a small border problem, alignment issue on Reading page.
0.832alpha: Rebuilds Navbar 2 from the top down, and adds some mobile awareness, again mostly cosmetic, but hopefully a bit more visual coherence nonetheless.
0.830alpha: Hands body font size back to user preferences, removing the hardcoded size used until now. The system default is 1em. This unit (em) is unreliable across browsers; I have changed my body type size to 14px and recommend the use of a px-based size generally.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
.82x fixes included Navbar 2 working better on Android browsers (Login panel is still a bit of a mess but I don't care, all that's going away in Navbar 3 anyway), comment thread depth indicators on mobile working even without subject lines, various overprint issues, and so on.
.81x fixes included user left-right selection of icon placement is honoured correctly again. As are icon sizes except on mobile comments where you're forced to "smallest" regardless. Also, the implementation was improved.
And if you see issues, please give me a screenshot and tell me your browser and OS. Thanks!
no subject
1) On some of the comment chains on this page, some content text is overlapping with footer links. A clear fix is needed due to your floats.
2) If DW is aiming for best practices involving responsive design, the CSS should be done mobile-first, since you're using max-width on media queries this is desktop-first css.
3) I wouldn't add border-radius to inputs, it makes them not look like an input, and in areas like in the control strip where you shrunk the size it makes the type very claustrophobic.
4) your idea for how you're handling the comment threads is interesting, however, instead of specifying a number for every comment depth in the css look into the css counter-increment property, it will auto count and spit out numbers for you.
I would also look into styling it so it's a little more clear what you were going for. I didn't notice the numbers at first and "#>" doesn't mean much, especially if it's your first time coming to a dw journal and you're on a phone.
I apologize if some of these suggestions were things you were going to work or approve on, haha.
I'm really glad someone is tackling this officially! Just having the viewport declared by default would make me a happy camper.
no subject
This reminds me: I have accessibility settings on for comments. The two nesting indicators both display.
no subject
screenshot?
fffft, how will I test for this, idek.
no subject
I know that setting was a check box somewhere...
no subject
http://www.dreamwidth.org/manage/settings/?cat=display
no subject
Can I get a screenshot and browser+OS info? Because that's not showing up in mine.
If DW is aiming for best practices involving responsive design, the CSS should be done mobile-first, since you're using max-width on media queries this is desktop-first css.
I don't want to speak for Dreamwidth, as I'm not an employee or contractor for them. I'm doing this to make a fully-working implementation that can be reimplemented in S2 as a new style which behaves the same way. A reference model, as it were.
I wouldn't add border-radius to inputs, it makes them not look like an input, and in areas like in the control strip where you shrunk the size it makes the type very claustrophobic.
You think so? Huh. Is this an accessibility issue? I dislike the hard points but if it's an issue I can go back to them.
4) your idea for how you're handling the comment threads is interesting, however, instead of specifying a number for every comment depth in the css look into the css counter-increment property, it will auto count and spit out numbers for you.
I'll look into that, thanks. I was using existing classes because they were there. :D
I would also look into styling it so it's a little more clear what you were going for. I didn't notice the numbers at first and "#>" doesn't mean much, especially if it's your first time coming to a dw journal and you're on a phone.
What I wanted to do, Dreamwidth's CSS parser won't let me do, even though it's legal CSS. Something breaks and the whole custom CSS structure gets dropped. I would welcome a better suggestion that doesn't break the Dreamwidth parser - I am not happy with #> either, but it works.
no subject
I'm on Chrome right now, using MacOS 10.12.4.
no subject
no subject
no subject
I was seeing the overlapping on Firefox on win 10 but I can't get a screenshot of that atm. On my galaxy android using Chrome there's no overlapping, bug there is little to no margin between the main comment content and footer links, caused by the same thing, see this:
http://imgur.com/a/5Zdbe
"I don't want to speak for Dreamwidth, as I'm not an employee or contractor for them. I'm doing this to make a fully-working implementation that can be reimplemented in S2 as a new style which behaves the same way. A reference model, as it were."
It is best practice to do mobile first, and can cut down on css code (and thus memory downloaded) because you won't be overriding as much... I see the base style you're building on is also doing min-width for its media queries so it's best to match it.
But, it might take more time for you, though, but in the end I find it worth it when I have to retrofit a sit for responsive. (I'm a front end developer and I've had many a-project retrofitting sites, so I get this pain, hah.)
"You think so? Huh. Is this an accessibility issue? I dislike the hard points but if it's an issue I can go back to them"
I do. It's not an accessibility issue insomuch a screen reader will break reading it, but it is one in terms of you're changing the expected look of something that can be confusing, especially with how small the fields now are they look like tiny buttons rather than inputs.
I think the rounded corners on the larger input fields, like in this comment box, are fine enough with the rounded corners, though, because they're larger and a lititle more clear what they are. I'm more concerned about the control strip.
"I'll look into that, thanks. I was using existing classes because they were there. :D"
I figured so! But the counter will make it less tedious and can go on infinitely, at least.
"What I wanted to do, Dreamwidth's CSS parser won't let me do, even though it's legal CSS. Something breaks and the whole custom CSS structure gets dropped. I would welcome a better suggestion that doesn't break the Dreamwidth parser - I am not happy with #> either, but it works."
I don't have a concrete idea off the top of my head and I can't play around with it atm (at work now), but just "Comment #1" would be more inuitive for the time being. I can revisit this later!
no subject
The problem with something large like "Comment #" is too much space taken up on mobile. But also, it's not a comment number, it's a depth of reply in chain number, which is the information I'm trying to convey in replacement form given that the actual physical depth is no longer available. And "Reply depth: #" is also large.
I'm still thinking about it. Maybe something like ↳ if the CSS parser will let me? (I kind of doubt it will tbh.)
no subject
no subject
no subject
(There are design documents involved as well as a bunch of images.)
no subject
no subject
no subject
That's no glitch... that's a secret feature.
If I don't do that (and a couple of other things), then you get auto-zooming and auto-repositioning on iOS when a text field is selected. It's an awful user experience that Apple considers a feature, and I - like so many other people - work to avoid triggering it as broadly as we can.
Re: That's no glitch... that's a secret feature.
I was viewing it on in a desktop browser; unfortunately (fixed-width) the font used in text areas is significantly larger than the body text -- I expect it's the system default, which I set to something that makes text editors and terminal windows usable. Possibly this isn't a problem for people who use the OS's default fonts.
Re: That's no glitch... that's a secret feature.
#qrform select, #qrform textarea, #qrform subject, #qrform body, input#subject.textbox, textarea#commenttext.textbox {
font-size: 16px;
}