I think we only find this obnoxious because we have a lot of things to fix. A new author is going to put in their first url with content and without @visual and get a deprecation warning. They’re pointed toward a resource on how to best handle these things. They will then write things thoughtfully from then on.
> Furthermore, it breaks DRY - it's quite possible that through human error, a visual attribute is not equivalent to its href. We should be automating this, not adding more work on authors.
I disagree about automating. Here’s a for instance of where this warning was legitimately useful in making Matt and me think about how to do things better: The “(Instructors|Students) Read This!” prefaces in ACS point to the YouTube playlists that go with the book. Pretty much all of the other links were added in the original authoring, so Matt had used the GVSU URL shortener and we had nice short links. These YouTube links were *massive*, and automagically getting that dumped out as the visual was *not* good. So realizing what was happening there, I asked Matt to run them through the URL shortener. I left the @href set to the YouTube.com URL, but the @visual is now something like gvsu.edu/s/blah
. Honestly, this should probably be part of the best practice…URL shorteners come and go, so you’d hate to have the @href become unreachable and then you might no clue what the link was meant to point to.
I would advocate that keeping the behavior of copying @href into @visual (ideally with the protocol stripped off) but still considering it invalid and issuing a deprecation warning. Then folks get something useful as output, but they also get pointed to a best practice on how to do things well.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-dev/e4ae3ff4-b0bf-4f0d-bc2e-90e7479b6474n%40googlegroups.com