github: shadowy octopus with the head of a robot, emblazoned with the Dreamwidth swirl (Default)
github ([personal profile] github) wrote in [site community profile] changelog2020-08-31 06:22 pm
  • Add Memory
  • Share This Entry

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

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.