Remove invalid CSS and the dead btnform block from forms.scss - #792
Merged
Merged
Conversation
forms.scss carried three declarations of the form `margin-bottom: 5px / 2`.
Sass never evaluated them: two literals with no parentheses emit the slash
verbatim, so the compiled CSS shipped `margin-bottom:5px/2`, which is invalid
and silently discarded by browsers.
Rather than convert them to math.div(), which would newly apply margins that
have never been in effect, they are deleted. Nothing designed for the values
involved -- 2.5px, 1.25px and 1.25px are artifacts of hardcoding numbers into
what was presumably variable arithmetic upstream.
Reach of each, measured against the built site:
btnform p dead -- see below
label dead -- the site has no <label> element at all, nor any
<textarea> or <select>
input, ... 47 <input> elements, all on one legacy page
(/software/haddock2.2/start_new/). Deleting preserves current
rendering exactly, since the invalid value already resolved
to no margin.
Also delete the whole `btnform { ... }` block. Line 3 read `btnform {` -- a bare
element selector for <btnform>, which is not an HTML element and appears zero
times in the site's markup. That made 30 lines of form styling dead, including
the first invalid declaration.
Renaming it to `form` was considered and rejected. On the one page that has
forms, every nested rule would still match nothing: there are no fieldset,
legend, p or ul elements inside those forms, and all four <br> sit before the
first <form> tag. It would activate only a 5px margin on three legacy forms,
while leaving `form br { display: none }` to silently hide line breaks in any
form added later.
Drop the unused `@use "sass:math"` while here; the file uses only color.*.
Verified: no invalid px/N values remain in the compiled CSS, no HTML page
changed, and the only selectors removed are the six btnform ones. The label and
input rules keep every other declaration.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Split out of #791 on review feedback — this is unrelated to that PR's CSS
pipeline fix and deserves its own review. It cherry-picked onto
mastercleanly,confirming the two are independent.
Two changes, both to
_sass/forms.scss1. Three invalid declarations deleted
The file carried three declarations of the form
margin-bottom: 5px / 2. Sassnever evaluated these — two literals with no parentheses emit the slash
verbatim, so the compiled CSS shipped
margin-bottom:5px/2, which is invalid andsilently discarded by browsers.
They are deleted rather than converted to
math.div(), because converting wouldnewly apply margins that have never been in effect. Nothing designed for the
values involved: 2.5px, 1.25px and 1.25px are artifacts of hardcoding numbers into
what was presumably variable arithmetic upstream.
Reach of each, measured against the built site:
btnform plabel<label>element at all, nor any<textarea>or<select>input, textarea, select<input>elements, all on one legacy page (/software/haddock2.2/start_new/)For the third, deleting preserves current rendering exactly: the invalid value
already resolved to no margin, so removing it changes nothing.
2. The dead
btnform { ... }block deletedLine 3 read
btnform {— a bare element selector for<btnform>, which is not anHTML element and appears zero times in the site's markup. That made 30 lines of
form styling dead code, including the first invalid declaration above.
Renaming it to
formwas considered and rejected. On the one page that hasforms, every nested rule would still match nothing — no
fieldset,legend,por
ulelements inside those forms, and all four<br>sit before the first<form>tag. Renaming would activate only a 5px margin on three legacy forms,while leaving
form br { display: none }primed to silently hide line breaks inany form added later.
Also drops the unused
@use "sass:math"— the file uses onlycolor.*. It wasleft behind by a reverted change in #789.
Verification
px/Nvalues remain in the compiled CSSbtnform*ones, all confirmed unmatchedlabelandinput,textarea,selectkeep every other declaration:Note on ordering:
mastercurrently serves the committedmain_pretty.css, sothis change has zero live effect until #791 lands — verified,
main_pretty.cssbuilds byte-identical here. The two PRs are safe to merge in either order.
Not addressed here
The same rule block sets
width: 100%on inputs, which overrides thesize=3/size=60attributes on that legacy HADDOCK 2.2 form. Left alone — it islong-standing behaviour and a separate question.
🤖 Generated with Claude Code