adswa
commented
11 months ago My thoughts are this:
-
I do not think its an issue in the web version. The shadow underneath the box and the colored box boundary make it pretty clear whether text is in-box or out-box, IMHO.
-
I agree on that this is not optimal in the printed version. We should change it if possible.
-
The reasoning for placing windows wits prior to commands is to spare Windows users the trouble of first pasting a wrong command and then finding the Windows-Wit. I believe this is a worthy nicety to keep in the web version.
The middle-ground would be to change the placement only in the print version, at the expense of another constant different between the printed version and the web version. I anticipate that this is annoying. But I believe we have a choice of the possible annoyances:
- make the web version less functional for windows users by moving the windows wits down
- make the printed book annoying for readers by keeping distracting boxes
- make our work more annoying by creating a discrepancy in placement between web version and printed version.
When forced to decide between the three, I'd opt for annoying us rather than any users.
mih
These boxes often directly precede command output displays. Example:
Visually, this looks as if the box is "unfolded" and the output IS the windows wit.
In the PDF version, the pattern "insert windows wit box BEFORE the content that it annotates" leads to substantial diversions. Example:
"this script" refers to a listing that follows two boxes (full-page length combined), with no particular emphasize that connects the text.
IMHO in-text boxes should be placed at semantic boundaries, not inside content that is directly connected.
This is a frequent pattern. The preceding text often even ends with a colon, but is followed by an in-text box, and not the content that belongs after the colon.