[dreamwidth/dw-free] 32d3d6: Fix icon browser on create entries page (#2836)

[github]

Branch: refs/heads/master Home: https://github.com/dreamwidth/dw-free Commit: 32d3d6eb9ee37016e0e38643613daf1f08f13c54 https://github.com/dreamwidth/dw-free/commit/32d3d6eb9ee37016e0e38643613daf1f08f13c54 Author: Nick Fagerlund nick.fagerlund@gmail.com Date: 2020-08-31 (Mon, 31 Aug 2020)

Changed paths: M htdocs/scss/components/icon-browser.scss M htdocs/scss/foundation/components/_reveal.scss M htdocs/scss/pages/entry/new.scss M views/components/icon-browser.tt M views/entry/module-access.tt

Log Message:

---

Fix icon browser on create entries page (#2836)

• Un-break the icon browser in beta create entries page

Somehow I missed this bug in my last icon browser PR.

Visible symptoms: "order by keyword" doesn't work when used on the create entries page, and some of the styling/alignment is a little wrong there too.

Underlying problem:

• The whole create entries page is wrapped in one bigass <form> element.
• It's illegal to nest a form inside a form.
• I used forms as container elements for the re-jiggered icon browser options toggles.
• The icon browser modal markup gets spawned inside the icons module, which is still inside the bigass top-level form element.
• Kaboom.

I assume this also broke some other stuff on that page, but who cares because let's just not do that; those nested form elements aren't needed anyway. (I used them initially because I thought I'd be using HTMLFormElement.elements to get the inputs, but I didn't end up doing that.)

• Create entries: Use normal fieldset/legend relationship in custom access modal

This was making the top-border on Foundation's fieldset styling look wrong.

• Create entries: Don't mess with fieldset borders in modals

This was causing the icon browser to look inconsistent between create entries and site-skin comment pages. After following it back, it looks like this was just to accommodate the weird markup in the custom access groups modal.

• Foundation modals: clear some space around the close button

In the last big foundation update, something changed with how things are spaced in reveal modals, which made it possible for the edges of elements (like the top border of a fieldset) to sometimes scoot underneath the close button. That looks a little confusing, so let's make the close button obscure the couple of pixels behind it by grabbing the same background color as the modal itself.

• Create entries: Fix button alignment when using custom access groups

The fancy selects squirted a few pixels out of alignment whenever the "edit" button appeared; this stops that.

[dreamwidth/dw-free] f90e63: Two minor reply form tweaks (#2831)

[github]

Branch: refs/heads/master Home: https://github.com/dreamwidth/dw-free Commit: f90e633e7d814817aa692edebab8d4d8b9d3e874 https://github.com/dreamwidth/dw-free/commit/f90e633e7d814817aa692edebab8d4d8b9d3e874 Author: Nick Fagerlund nick.fagerlund@gmail.com Date: 2020-08-31 (Mon, 31 Aug 2020)

Changed paths: M htdocs/js/jquery.quickreply.js M htdocs/scss/components/quick-reply.scss M htdocs/scss/skins/_journal-typography.scss

Log Message:

---

Two minor reply form tweaks (#2831)

• Comment preview: use same reply form font as other site skin pages

The rules that affect entries and comments weren't affecting the parent wrapper for the preview page. That was mostly fine, because the preview itself and the parent post both use fake wrappers to make sure they get the right styles. But the talkform appears outside those, as its own element, so it was missing the rules. Thus, the textarea was at the mercy of whatever default or inherited styles applied, probably browser-dependent.

• Reply form: Allow a little more max-width on desktop

On site-skin comment pages, the 16px font for textareas just makes the max starting width feel too cramped.

[dreamwidth/dw-free] 686db9: Fix printing on Foundation site skins (#2828)

[github]

Branch: refs/heads/master Home: https://github.com/dreamwidth/dw-free Commit: 686db9c24ebc81f4a260e6c4d0d2d36d36ca62ef https://github.com/dreamwidth/dw-free/commit/686db9c24ebc81f4a260e6c4d0d2d36d36ca62ef Author: Nick Fagerlund nick.fagerlund@gmail.com Date: 2020-08-31 (Mon, 31 Aug 2020)

Changed paths: A htdocs/scss/components/foundation-custom/print.scss M htdocs/scss/foundation/settings.scss M htdocs/scss/foundation/foundation.scss M htdocs/scss/skins/_nav.scss

Log Message:

---

Fix printing on Foundation site skins (#2828)

Printing an entry+comments page on the new site skins pretty much just EXPLODES. Shoutout to anaraine and AlexSeanchai in the Discord for raising the issue.

First set of problems is in Foundation's print styles, which "helpfully" add the URL after every link (including tiny chiclet icon links that carry no meaning in print). So let's turn those off and add our own reduced set, because flipping font to black and expanding abbreviations is still a pretty good idea.

Second set of problems involves the positioning of account links and the user's icon in the header, but those are straightforward fixes too.

Third set of problems is specific to Tropo, which cuts off everything after the first page. 😱 Addressed in dreamwidth/dw-nonfree#142.

After that we get into the innate problems that already existed on the old skins -- showing threading through indentation alone makes a truly impossible mess when printing deep threads, and that can't be fixed without a total rethink of the threading styles. But at least this commit (plus nonfree 142) gets us back to status quo ante.

[dreamwidth/dw-nonfree] c150ab: Tropos: Limit canvas border positioning hack to sc...

[github]

Branch: refs/heads/master Home: https://github.com/dreamwidth/dw-nonfree Commit: c150ab8a17db62110b8de2f9dbc183d80d897c88 https://github.com/dreamwidth/dw-nonfree/commit/c150ab8a17db62110b8de2f9dbc183d80d897c88 Author: Nick Fagerlund nick.fagerlund@gmail.com Date: 2020-08-31 (Mon, 31 Aug 2020)

Changed paths: M htdocs/scss/skins/tropo/_tropo-base.scss

Log Message:

---

Tropos: Limit canvas border positioning hack to screen only (#142)

This has a nasty effect on print -- it ends up cutting off the content after the first page, because the page height gets treated as the height of the container.