refactor(classifier): use native browser SVG scaling for drawing tools

[eatyourgreens]

• remove manual scaling code from strokeWidth for all the SVG drawing marks. To be honest, it has never worked very well. When I wrote it, I didn't know that you can disable stroke scaling programmatically in SVG.
• add vector-effect="non-scaling-stroke" to all the SVG drawing marks. This will make the displayed stroke width independent of the scaling of the SVG <image>, at all zoom levels.
• style marks with :focus-visible so that the focus ring is only shown for keyboard interactions.

Screen.Recording.2024-04-28.at.12.06.37.mov

Package

• lib-classifier/plugins/drawingTools

Linked issues

• Fixes Correct-A-Cell line styles vary from subject to subject #6167.

How to Review

This staging workflow has a mixture of drawing tools:
https://localhost:8080/?project=908&workflow=3370

A couple of workflows that use freehand lines:

• Etch-A-Cell: https://localhost:8080/?project=h-spiers%2Fetch-a-cell&env=production&workflow=8921
• Correct-A-Cell: https://localhost:8080/?project=willcharlie/etch-a-cell-correct-a-cell&env=production&subject=93925884

Wildwatch Burrowing Owl uses the rectangle drawing tool:

• https://localhost:8080/?project=sandiegozooglobal/wildwatch-burrowing-owl&env=production

You can also try out the drawing step in the I Fancy Cats workflow or try out a transcription task, with annotations from Caesar:
https://localhost:8080/?project=mainehistory/beyond-borders-transcribing-historic-maine-land-documents&env=production

You can test the focus styling by tabbing through the page, to check that drawn marks have focus styling when focused (WCAG Success Criterion 2.4.7: focus visible.) When a mark has keyboard focus, Enter will open any associated subtask popup, which should also be fully keyboard accessible. Backspace will delete the focused mark (WCAG Success Criterion 2.1.1: Keyboard.)

Screenshots

Each of these screenshots is taken from a production build of the project app, running in Firefox 128. Subject scale is clientWidth / naturalWidth for the subject image. Scaling shouldn't make a difference on this branch, but does affect the rendered stroke width in production.

Wildwatch Burrowing Owl with an active (6px stroke) and inactive (3px stroke) rectangle (subject scale: 0.44):

https://local.zooniverse.org:3000/projects/sandiegozooglobal/wildwatch-burrowing-owl/classify/workflow/26173

Correct-A-Cell with a 1200px subject (scale: 0.74):

https://local.zooniverse.org:3000/projects/willcharlie/etch-a-cell-correct-a-cell/classify/workflow/24998/subject/93925784

Correct-A-Cell with a 600px subject (scale: 1.48):

https://local.zooniverse.org:3000/projects/willcharlie/etch-a-cell-correct-a-cell/classify/workflow/24998/subject/93925884

Checklist

PR Creator - Please cater the checklist to fit the review needed for your code changes.
PR Reviewer - Use the checklist during your review. Each point should be checkmarked or discussed before PR approval.

General

• Tests are passing locally and on Github
• Documentation is up to date and changelog has been updated if appropriate
• You can yarn panic && yarn bootstrap or docker-compose up --build and FEM works as expected
• FEM works in all major desktop browsers: Firefox, Chrome, Edge, Safari (Use Browserstack account as needed)
• FEM works in a mobile browser

General UX

Example Staging Project: i-fancy-cats

• All pages of a FEM project load: Home Page, Classify Page, and About Pages
• Can submit a classification
• Can sign-in and sign-out
• The component is accessible
  • Can be used with a screen reader BBC guide to VoiceOver
  • Can be used from the keyboard WebAIM guide to keyboard testing
  • It is passing accessibility checks in the storybook

Refactoring

• The PR creator has described the reason for refactoring
• The refactored component(s) continue to work as expected

[coveralls]

coverage: 79.073% (+0.01%) from 79.061%
when pulling 3cecfd5 on eatyourgreens:drawing-non-scaling-stroke
into 00089ff on zooniverse:master.

[goplayoutside3]

A couple of comments below, and just linking :focus-visible for documentation.

[goplayoutside3]

Should GRAB_STROKE_WIDTH still be divided by scale in this file?

[goplayoutside3]

The stroke width of each mark on a Correct-a-Cell project is much thinner on this branch than production.

[eatyourgreens]

All stroke widths should be constant on this branch.

It’s been a while since I looked at the drawing code, but freehand lines might override the default stroke width, which is quite thick.

[eatyourgreens]

Visible stroke width for freehand lines is 1px on this branch, but maybe it should be 2px, or whatever the default stroke width is.

[eatyourgreens]

I've changed STROKE_WIDTH to 2px for freehand lines. I'm not sure why it was set to 1, when other tools use 2. Easy enough to change back, though.

[eatyourgreens]

Some links for testing:

• Etch-A-Cell: https://localhost:8080/?project=h-spiers%2Fetch-a-cell&env=production&workflow=8921
• Correct-A-Cell: https://localhost:8080/?project=willcharlie/etch-a-cell-correct-a-cell&env=production&subject=93925884

When you compare those in production, you can see that Correct-A-Cell lines are thicker than Etch-A-Cell lines. They should be the same on this branch, and Etch-A-Cell freehand lines should be the same width here and in production (I think.)

I've been using Etch-A-Cell, in production, as the comparison for freehand line styling.

[eatyourgreens]

For Correct-A-Cell in production, the thickness of the freehand line tool even varies from one subject to another, because the subjects are different scales. I've opened #6167, but that should be fixed here.

[eatyourgreens]

Please double check all drawing tools on this branch in comparison to production.

Here's a couple of different-sized Correct-A-Cell subjects. The 1200px subject will be the same stroke on this branch and in production. The 600px subject has a thinner stroke, but a thicker rendered line, in production, because the scale multiplier is twice as large (1200/600) but the stroke width isn’t halved in the code. Both subjects should have the same thickness line on this branch, where image scale is handled by the browser and developers don’t have to remember to scale stroke width to subject image size in their code.

• 1200px subject: https://localhost:8080/?project=willcharlie/etch-a-cell-correct-a-cell&env=production&subject=93925784
• 600px subject: https://localhost:8080/?project=willcharlie/etch-a-cell-correct-a-cell&env=production&subject=93925884

[eatyourgreens]

That's going to introduce a complication into the analysis of their beta classifications, since the line width wasn't constant from subject to subject. 😕

EDIT: even for the same subject, the line width will vary from volunteer to volunteer, according to the client width of the image in their browser.

[eatyourgreens]

@goplayoutside3 the stroke width in production depends on both the subject image size (naturalWidth) and the rendered image size in the browser (clientWidth.) If you want me to match production styles, you’ll need to specify the subject image width and the subject viewer width, so I know what image scale to aim for. Roughly speaking, the production stroke width in SVG pixels is 2 * naturalWidth / clientWidth for all the drawing tools except freehand lines.

Freehand lines use a scaling function that generates thicker lines for smaller subjects (or smaller browser windows.) See #6167 (comment)

All that means that if I want to match what you’re seeing, I need to know how much your browser is scaling the image by. It also means that individual volunteers for the Correct-A-Cell beta would have seen different line widths, depending on both the subject size and the size of their browser window.

[goplayoutside3]

Drawing a new transcription line on this branch gives it stroke = GRAB_STROKE_WIDTH, which is 12. Is that intentional?

This branch:

Production:

[eatyourgreens]

The line with GRAB_STROKE_WIDTH has opacity 0, so that’s fine.

It does look like the default stroke width is quite thick here. The visible line is the first line in the code (line 42.)

Line 43 is an invisible line that captures pointer events.

[eatyourgreens]

I think the visible stroke width is 2px here.

[eatyourgreens]

I've updated transcription lines to explicitly set a stroke width of 2px.

[eatyourgreens]

Unlike all the other drawing tools, transcription lines aren’t composed from Mark components. That’s odd.

[eatyourgreens]

For consistency with the other drawing tools, I’d recommend wrapping transcription lines in Mark, so that they are composed from the same base settings as other tools. I haven’t done that here as it might be a breaking change for transcription workflows.

[eatyourgreens]

All the other drawing tools are wrapped in Mark here:

front-end-monorepo/packages/lib-classifier/src/components/Classifier/components/SubjectViewer/components/InteractionLayer/components/DrawingToolMarks/DrawingToolMarks.js

Lines 78 to 117 in 68a3e2b

	<Mark
	key={mark.id}
	isActive={isActive}
	coords={mark.coords}
	disabled={disabled}
	dragStart={selectMark}
	dragMove={moveMark}
	dragEnd={endMoveMark}
	label={`Mark ${index}`}
	mark={mark}
	onDelete={deleteMark}
	onFinish={onFinish}
	onSelect={selectMark}
	pointerEvents={isActive ? 'painted' : pointerEvents}
	scale={scale}
	>
	<MarkingComponent
	active={isActive}
	mark={mark}
	onFinish={onFinish}
	scale={scale}
	played={played}
	/>
	{isActive && mark.tool.type !== 'freehandLine' && (
	<DeleteButton
	label={`Delete ${tool.type}`}
	mark={mark}
	scale={scale}
	onDelete={deleteMark}
	onDeselect={deselectMark}
	/>
	)}
	{isActive && mark.tool.type == 'freehandLine' && (
	<LineControls
	mark={mark}
	scale={scale}
	onDelete={deleteMark}
	/>
	)}
	</Mark>

[eatyourgreens]

This fixes a bug where zooming in or out moves the delete button on the ellipse tool for I Fancy Cats.

[eatyourgreens]

I've based these numbers on a scale of 0.67 but feel free to adjust them.

These set the styles for all drawing tools except the transcription line and freehand line, each of which has its own custom styles.

[eatyourgreens]

Also noting that I used the live Wildwatch Burrowing Owl project (PFE) as my reference for the stroke widths. The production classifier in the monorepo uses stroke widths that are much larger (for this image scale.)

PFE (live project):

FEM:

[eatyourgreens]

If you'd prefer thicker drawing strokes for migrated projects, just adjust the numbers in the Mark component.

[eatyourgreens]

just linking :focus-visible for documentation.

By the way, focus-visible styling is already used by production single and multiple question tasks, so this just brings the drawing tools in line with those.

front-end-monorepo/packages/lib-classifier/src/plugins/tasks/single/components/SingleChoiceTask.js

Lines 12 to 15 in 68a3e2b

	&:focus-visible {
	outline: none;
	${props => props.focusColor && css`box-shadow: 0 0 2px 2px ${props.focusColor};`}
	}

front-end-monorepo/packages/lib-classifier/src/plugins/tasks/multiple/components/MultipleChoiceTask.js

Lines 13 to 16 in 68a3e2b

	&:focus-visible {
	outline: none;
	${props => props.focusColor && css`box-shadow: 0 0 2px 2px ${props.focusColor};`}
	}