- From: <bugzilla@jessica.w3.org>
- Date: Mon, 01 Oct 2012 21:51:24 +0000
- To: public-texttracks@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19178 Summary: Don't adjust position when snap-to-lines flag is not set Product: TextTracks CG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: WebVTT AssignedTo: ian@hixie.ch ReportedBy: lorettaguarino@google.com QAContact: dave.null@w3.org CC: mike@w3.org, public-texttracks@w3.org The cue text rendering rules are different when snap-to-lines is set and when it is not set. When it is not set: 1. The first step recalculates x and y, although snap-to-lines has already been considered in step 9. I believe the results are the same, but it is confusing and a potential source of error if the two ever get out of sync. 2. But more important, the next step repositions the boxes, based on the current position value. This has a number of unfortunate effects: * If the author knows where the caption should be positioned, and that position is neither centered nor against the left or right edge, it is very difficult to calculate what value to set for position so that the adjustment yields the desired location. * For align:middle captions, it is impossible to position the cue anyplace but centered in the viewport, since the adjustment will always move the 50% position of the box to the 50% position of the viewport. So no centering captions in the left half of the viewport, for instance. * Captions that are positioned against either edge are not repositioned. Since this is a common case, the repositioning often isn't noticed or needed at all. Changing line position from line number to percentage should not have this effect on the text position. I request that when snap-to-lines is not set, the values of x and y be used as computed, without adjustment, then repositioned to address any overlaps. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Monday, 1 October 2012 21:51:26 UTC