- From: Glenn Adams <glenn@skynav.com>
- Date: Fri, 1 Aug 2014 11:33:48 -0600
- To: Pierre-Anthony Lemieux <pal@sandflow.com>
- Cc: Nigel Megitt <nigel.megitt@bbc.co.uk>, Timed Text Working Group <public-tt@w3.org>
- Message-ID: <CACQ=j+cJfEUburPiSnttmdQfOxkqd2-ePvGAJfPRC=YgPEjwjQ@mail.gmail.com>
On Fri, Aug 1, 2014 at 11:32 AM, Glenn Adams <glenn@skynav.com> wrote: > Keep in mind that if some element E is not visible, then all of its > children are not visible regardless of their visibility property. > To clarify, I mean if not visible due to computedValue(tts:visibility) == hidden. That is, the computed value of tts:visibility also prevents rendering of descendants. > > > On Fri, Aug 1, 2014 at 11:17 AM, Pierre-Anthony Lemieux <pal@sandflow.com> > wrote: > >> Hi Glenn, >> >> Thanks. Sounds good. >> >> Per Nigel's earlier question: is specifying "inherited:yes" in the >> attribute definition sufficient to enable inheritance similar to that >> of tts:display? >> >> Thanks, >> >> -- Pierre >> >> >> On Fri, Aug 1, 2014 at 6:51 PM, Glenn Adams <glenn@skynav.com> wrote: >> > >> > On Fri, Aug 1, 2014 at 10:21 AM, Pierre-Anthony Lemieux < >> pal@sandflow.com> >> > wrote: >> >> >> >> Hi Glenn, >> >> >> >> > Then it needs to be changed. >> >> >> >> What about the following: >> >> >> >> "If the value of displayForcedOnlyMode is "true", a content element >> >> with a itts:forcedDisplay computed value of "false" shall be invisible >> >> (fully transparent), but still affects layout, regardless of the value >> >> of tts:visibility." >> > >> > >> > s/shall be invisible (fully transparent)/shall not produce any visible >> > rendering/ >> > >> >> >> >> >> >> Thanks, >> >> >> >> -- Pierre >> >> >> >> On Fri, Aug 1, 2014 at 5:59 PM, Glenn Adams <glenn@skynav.com> wrote: >> >> > >> >> > >> >> > On Fri, Aug 1, 2014 at 9:19 AM, Nigel Megitt <nigel.megitt@bbc.co.uk >> > >> >> > wrote: >> >> >> >> >> >> On 01/08/2014 16:01, "Glenn Adams" <glenn@skynav.com> wrote: >> >> >> >> >> >> >> >> >> On Fri, Aug 1, 2014 at 7:51 AM, Timed Text Working Group Issue >> Tracker >> >> >> <sysbot+tracker@w3.org> wrote: >> >> >>> >> >> >>> ISSUE-331 (forcedDisplay region background note): An advisory note >> on >> >> >>> the >> >> >>> use of backgrounds on regions in combination with forcedDisplay >> [TTML >> >> >>> IMSC >> >> >>> 1.0] >> >> >>> >> >> >>> http://www.w3.org/AudioVideo/TT/tracker/issues/331 >> >> >>> >> >> >>> Raised by: Nigel Megitt >> >> >>> On product: TTML IMSC 1.0 >> >> >>> >> >> >>> This issue is created to fulfil Action-314. >> >> >>> >> >> >>> Rationale: >> >> >>> >> >> >>> Since forcedDisplay affects the computed value of the >> tts:visibility >> >> >>> property >> >> >> >> >> >> >> >> >> Actually it doesn't change the computed value of tts:visibility (or >> >> >> shouldn't). It qualifies how the computed value is used, e.g., by >> doing >> >> >> something like: >> >> >> >> >> >> if (computedValue('tts:visibility') == 'visible') { >> >> >> if (!displayForcedOnlyMode || >> (computedValue('itts:forcedDisplay') != >> >> >> 'false')) { >> >> >> renderContent() >> >> >> } >> >> >> } >> >> >> >> >> >> >> >> >> >> >> >> That would be one way to do it, but the current spec does seem to >> state >> >> >> that the tts:visibility computed value should change. >> >> > >> >> > >> >> > Then it needs to be changed. >> >> > >> >> >> >> >> >> >> >> >> Aren't they completely equivalent though? >> >> > >> >> > >> >> > No, since computed values are referenced elsewhere, e.g., >> inheritance. >> >> > >> >> >> >> >> >> I don't see what the difference would be between your algorithm and: >> >> >> >> >> >> if (!displayForcedOnlyMode || (computedValue('itts:forcedDisplay') >> >> >> !='false')) { >> >> >> setComputedValue('tts:visibility', 'visible') >> >> >> } >> >> >> >> >> >> if (computedValue('tts:visibility')=='visible') { >> >> >> renderContent() >> >> >> } >> >> > >> >> > >> >> > The problem is that computed value is referenced elsewhere, and this >> >> > logic >> >> > shouldn't impact it. >> >> > >> >> >> >> >> >> >> >> >>> it has no effect on whether or not the hidden/visible content is >> >> >>> temporally active. This means that if non-forced content is >> assigned >> >> >>> to a >> >> >>> region with a background colour then the background will be shown >> >> >>> whenever >> >> >>> the content is active even if it is hidden. This is likely to be >> >> >>> unexpected >> >> >>> behaviour for some readers of the specification, who may imagine >> that >> >> >>> by >> >> >>> using a setting of tts:showBackground of "whenActive" they can >> prevent >> >> >>> this >> >> >>> effect. >> >> >>> >> >> >>> (incidentally they'd be correct in thinking this if forcedDisplay >> were >> >> >>> changed to do what its name suggests and affect tts:display, which >> >> >>> arguably >> >> >>> would be more useful functionality) >> >> >>> >> >> >>> Proposal: >> >> >>> >> >> >>> Include a non-normative note such as the following: >> >> >>> <-- >> >> >>> NOTE >> >> >>> >> >> >>> If the forcedDisplay attribute is used for content in combination >> with >> >> >>> regions that have a non-transparent computed background color then >> >> >>> authors >> >> >>> should be aware that those regions' backgrounds will be drawn >> whenever >> >> >>> the >> >> >>> selected content is active, even if the computed tts:visibility of >> >> >>> that >> >> >>> content is "none". >> >> >> >> >> >> >> >> >> Note that the two legal values of tts:visibility are 'visible' and >> >> >> 'hidden'. The values 'none' and 'false' and 'true' are not legal. >> [IMSC >> >> >> ED >> >> >> currently refers to an illegal value 'true'. >> >> >> >> >> >> >> >> >> Yes, sorry, my mistake – as Pierre also pointed out I meant >> "hidden" in >> >> >> place of "none". >> >> >> >> >> >> >> >> >> BTW, I'd still like to see the name changed to itts:forced in order >> to >> >> >> avoid the display vs visibility confusion. >> >> >> >> >> >> >> >> >> >> >> >> I'd like to see it changed to itts:forcedVisibility to make it even >> >> >> clearer, if we're going to change the name at all. >> >> >> >> >> >> >> >> >>> One strategy for avoiding this scenario would be to assign content >> >> >>> elements only to regions that have the same value of forcedDisplay. >> >> >>> --> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >> >> >> > >> > >> > >> > >
Received on Friday, 1 August 2014 17:34:36 UTC