[Bug 28257] [webvtt] start/end linked to left/right [I18N-ISSUE-422]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28257

--- Comment #9 from Addison Phillips <addison@lab126.com> ---
I'm not sure I agree with what has happened here. Reading the text Richard
supplied that appears in the patch, I felt we were "on track", but reading the
specific text for processing makes me think we haven't addressed the original
problem.

In CSS there is a difference between the direction neutral keywords
'start'/'end' and the direction specific keywords 'left'/'right'. (Ditto their
vertical friends 'before'/'after' and 'top'/'bottom'). The difference is that
the direction or writing mode of the text affects the meaning of the direction
neutral flavored items. In an RTL context, 'start' means 'right' and 'end'
means 'left'. This is done so that when the base direction of the layout
changes (for example: you localize the file), you don't have to go through and
rebuild all of the positioning "backwards". It just works.

I understand the problem of needing to position cues under a specific part of
the screen (such as which side the speaking character appears on). In this
case, you would want to use direction-specific keywords like 'left' and 'right'
to ensure that the cue box doesn't "mirror" when the language is changed to
Arabic and end up on the wrong side. But in other, more general, cases, you
*do* want the mirroring to occur.

In looking at the text this morning I see the formal description of these words
in Section 3.1 under 'position' says:

---
If the cue text alignment is start or left, return 0 and abort these steps.

If the cue text alignment is end or right, return 100 and abort these steps.

If the cue text alignment is middle, return 50 and abort these steps.
---

This means that the direction neutral words are just synonyms for their
direction specific brethren and we haven't solved the problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 23 November 2015 18:34:32 UTC