- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Wed, 11 Dec 2013 16:46:02 +0000
- To: Glenn Adams <glenn@skynav.com>
- CC: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <CECE3E3E.1627D%nigel.megitt@bbc.co.uk>
On 11/12/2013 15:25, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:
On Wed, Dec 11, 2013 at 10:10 PM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:
On 09/12/2013 21:28, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:
On Tue, Dec 10, 2013 at 12:05 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:
On 06/12/2013 18:34, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:
On Fri, Dec 6, 2013 at 10:52 PM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:
On 05/12/2013 23:25, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:
body: Since tts:padding is not inheritable and body can not contain content (i.e. what's in the spec as Inline.class) I'm not sure how it would ever be applied.
yes, body contains content, in fact, all content; body maps to fo:block in XSL-FO and will map to an outer div in HTML
Which rendered text would the padding apply to, given that the only content that body can contain is zero or more divs, and divs have a padding attribute of their own, which is not inheritable?
not related to inheritance, each generated block area (box) has its own padding; think of it as a set of nested blocks, each with separate padding:
body padding
Is this the first instance of a box being explicitly required for the body, rather than merely an implicit concept?
In TTML1, we allowed padding on region only. In TTML2 it has been proposed to support padding on content elements, which means body, div, p, span (doesn't make sense on br though). It would be strange to define only for some subset of body, div, p, span.
Alternately it's strange to define functionality for which no requirement has been stated. In my view it's sufficient to go ahead with the proposal for padding on body if it will make implementation simpler, but if we can not demonstrate that and we have no requirement then we should prune down to the requirement.
Since we are relying on external definitions of rendering, namely XSL-FO or CSS, we should attempt to stay close to their models where possible without creating exceptions. If one were to look at how we selected the current style properties, it is clear that we simply adopted featuresf in a number of cases for which there was no initial hard requirement. This was done primarily to avoid exceptions, meaning exceptions for testing, for spec readability, for authorial expectations (for those already familiar with the XSL-FO or CSS properties).
If exceptions -> implementation complexity then I think we're agreeing. However since we don't actually need to enforce a concrete layout object for body, and can keep it implicit/abstract, wouldn't it be better to do so?
div1 padding
div1.1 padding
p1 padding
div: Could apply to the set of rendered lines within the div, taken as a single rectangle? This is subtly different from padding on region, which doesn't take into account the width of the rendered lines at all, so I can see it being useful.
again, the XSL-FO (=CSS) model applies; padding applies to the block areas (boxes) generated by div
Is that different in effect from the box tightly surrounding all the (i.e. not "each of the…") rendered lines generated from content contained in the div?
not sure what you mean by the box; each of body, div.outer ... div.inner, p generate block areas (boxes), and each has independent padding; see diagram at [1]; the body has its own padding, then each of its div children generate areas placed into the body's content rectangle, where each div has its own padding
[1] http://www.w3.org/TR/2006/REC-xsl11-20061205/#area-intro
e.g. in the following example, there would be 175px of padding to the left of FIRST LINE with respect to the left edge of the region
<region xml:id="r1" tts:padding="100px"/>
...
<body tts:padding="5px" region="r1">
<div tts:padding="10px">
<div tts:padding="20px">
<p tts:padding="40px">FIRST LINE</p>
</div>
</div>
</div>
Just want to double check that we have the same understanding on this one. Also that it's not in effect identical to padding on region.
Definitely not identical.
p: as per proposal, applies separately to each rendered line within the p.
not exactly, padding applies to the (non-line) block areas (boxes) generated by p
This appears to be a duplicate of the functionality provided by padding on div.
Don't know what you mean by duplicate. It is separate and independent.
Forgive my phrasing – I mean if you want to create padding on the block that contains all the child elements' (non-line) block areas you can do this with div. There doesn't seem to be an option that permits padding on each of the child elements' line block areas separately.
Line block areas (boxes) are generated only by p. The padding on p applies to p as a whole, which means it consumes area around its content area into which it may place line block areas.
Line block areas are not individually addressable (or styleable) in general, so one can't specify a padding for, say, line 2 of a paragraph.
I think it's possible from your proposal to put each line in a separate span and apply padding that way – is that how you expect the requirement to be met?
The requirement is focused on being able to paint a background color behind text such that it extends outside of the text in the inline progression axis. This appears to be satisfiable with either whitespace characters or padding (on span) or a combination of both.
What doesn't seem to be satisfiable in the proposal is the ability to extend the background color in the inline progression axis mid-line without introducing a non-spacing word separation character, which would be making a content change to satisfy the presentation requirement. As we strongly prefer not to mix content with presentation this isn't ideal but I don't think it's enough to create an objection.
Just to make this more clear, since some may misunderstand, what you want is to have padding on span be conditional, where the padding would appear when the span boundary appears within a line, but not appear when it appears at the start or end of a line.
No, I'm not suggesting that there needs to be conditionality on padding in this sense. What I want (ideally) is for mid-line padding to extend the background painting area without affecting the foreground text layout at all. This would allow the background extension to be applied to spans mid-line without editing the span's text content.
However it would be useful to have padding conditionality in the reverse sense, i.e. to specify that the padding appears at line boundaries but not mid-line. Otherwise if you want to set the background color on a word in a line with padding then you might have to go from:
<p><span padding="0c 1c 0c 1c">This is a line of text</span></p>
to:
<p> span padding="0c 0c 0c 1c">This is a </span><span padding="0c 0c 0c 0c" backgroundColor="green">line</span><span padding="0c 1c 0c 0c"> of text</span></p>
which means that the author needs to be aware of the impact of changing the word styling on other style attributes elsewhere in the document.
Whereas if line padding were a separate concept or attribute from generic inline block padding this careful management of padding start and end values wouldn't be required and the solution could apply it to each rendered line regardless of whether the author or the implementation provided the line breaks.
This was the intention behind the original proposal of applying this meaning to padding on p, which seemed to be the best place to put it at the time, though this thread suggests it isn't.
Clearly, as defined in both XSL-FO and CSS, this is not currently supported: padding on a span will always appear as presently defined.
To remediate this further I propose that when we define a feature designation for padding on span we create a specific designator for arbitrary padding on spans and another more restricted designator for padding that is applied only when it occurs at line start and end.
Sure, we could do that, in which case requiring support for the the more specific designator also effectively signals that padding at start/end of line on span must be ignored. Note that it may be difficult to demonstrate implementations of such a feature though.
I meant it to be the other way round, i.e. that it should be possible to support padding at line start and end only and not support mid-line padding.
In the absence of an explicitly line-based entity we haven't yet met the use case: padding on p seems to be the best place to put it given the duplication.
Not sure what you mean by duplication.
As above.
It can't go on span because line breaks are not predictable, unless we add the specification that in mapping to CSS box-decoration-break shall be "clone". Padding on span also has the problem described below.
span: applies to the contained text within the span.
more accurately, applies to the inline areas (boxes) generated by span
Right, yes. I meant that.
Adds to or overrides p-based tts:padding values?
padding on p and spans are treated separately and independentlty
Does this affect the interpretation of lineHeight?
It doesn't affect the computed value of tts:lineHeight. As for the actual height assigned to specific line areas (boxes), and since spans are non-replaced content, the following (from CSS2.1) applies [2]:
"Although margins, borders, and padding of non-replaced elements do not enter into the line box calculation, they are still rendered around inline boxes."
[2] http://www.w3.org/TR/CSS2/visudet.html#leading
I.e. is new lineHeight effectively increased by the padding on span to be lineHeight + padding_before + padding_after?
I think by "lineHeight" here you mean "line area (box) height". So the answer is no. Please keep in mind that the "line area(box) height" is not necessarily the same as the computed value of the tts:lineHeight property; that is, the following holds:
line area box height >= computed value(tts:lineHeight)
That's true but not what I was trying to get at.
Is the baseline spacing = line area box height + padding_before + padding_after, where line area box height takes into account leading already?
No. First padding (on either p or span) doesn't affect height of line areas. Second, baseline spacing depends on which fonts are used on a line. If we include leading in the height of a line box, then the height of a given line area is computed as:
height(line) :=
max(
leading(line) + max(ascent(inline area)) + max(descent(inline area)),
computedValue(tts:lineHeight)
)
This value may vary between lines, so baseline spacing is (in general) non-constant over a paragraph. It would be constant if the same font applies to all content in the paragraph or if computed value of tts:lineHeight is greater than the maximum of all fonts' ascent plus descent plus line gap.
So, again to check my understanding, the background painting dimensions are affected by padding on span in the block progression direction but the foreground text layout is not affected at all (though it would be affected by padding in the inline progression direction). In which case if padding before or after is applied both to region and to a span around a line does that mean it is possible for a background to extend outside the region, if for example padding_span > padding_region, or does the region clip the background painting?
It depends on whether tts:overflow on region is visible or hidden. The initial value is hidden, so would be clipped; but if set to visible, then a padding in before or after dimensions on a span could cause the line area containing a portion of the span to extend outside the region's allocation rectangle.
I hadn't thought of that - makes sense.
Either way this is the most problematic one: the padding creates spacing that is normally created using a spacing text character, which gives the author a no-win problem: either create spans with padding to make spacing correct, and remove space characters from text, or have unwanted extra spacing, dependent on line wrapping.
i don't see any overlap between padding and spacing characters; they are quite distinct
Start and end padding creates a similar visual effect to spacing characters, and the two act additively in how much space is created, so they're not distinct when rendered. The "colour the background behind a word and extend it to half way between that word and the adjacent word's background" use case that John described shows how they are not distinct, at least if padding affects layout. To demonstrate:
<p tts:backgroundColor="black">
<span tts:padding="0c 0.5c 0c 1c">A word on a</span>
<span tts:backgroundColor="green" tts:padding="0c 0.5c 0c 0.5c">green</span>
<span tts:padding="0c 1c 0c 0.5c">background</span>
</p>
would render (in laid out foreground text) the same as:
<p tts:backgroundColor="black">
<span>A word on a green background</span>
</p>
assuming that 1c has been arranged to be equal to the width of one space character. The former example has two space characters missing. The background colours could have been omitted altogether to give exactly the same rendering.
Are you trying to achieve something like the attached?
Yes. Actually it's a secondary use case. The primary use case is the spacing at the beginning and end of a line, where that's known.
Unfortunately CSS doesn't provide any way to address individual line areas, so one can achieve this using only indirect means.
See Andreas's proposal in a previous email on this thread that we request a ::lines pseudo element to permit this. In the meantime padding on span is the closest we can get, with the constraint that authors must define line breaks if they require this behaviour on each line.
We now have two potential requests for CSS: remove box-decoration-break from being at risk; add a ::lines pseudo element. Do we actually need both or would either work?
I don't believe the box-decoration-break will provide the conditional padding you seek; it was designed to ensure the presence (clone) of padding at line breaks, and not suppress the padding at start/end of line. However, we could propose a 'clone-except-at-line-start-or-end' value. I suspect that would be more readily accepted by the CSS WG than a ::line(s) selector.
Reversing the conditional padding issue from what you suggested (as above) would mean that box-decoration-break="clone" would indeed do what we need, yes?
The cost of removing space characters from the text is that meaning is removed – some processors might for example pre-process by removing all formatting (e.g. for indexing), leading to weird compound words where the space has been removed.
Agree this could be a problem, as shown in the third example HTML in the attached, where it was necessary to remove spaces between spans.
However, as shown in the fourth example in the attached, this can be fixed by inserting ZERO-WIDTH SPACE (​) to ensure the presence of a space boundary.
This works because you were able to discover that the width of a space character is 24px for a 40px monospace font, but wouldn't work in general if the width of the space character is not predictable.
Correct.
This is a general problem if background padding is needed to change the background between words, since we can't make any guarantees about the width of the space character – see my proposal for feature designators above to handle this.
Kind regards,
Nigel
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
---------------------
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
---------------------
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
---------------------
Received on Wednesday, 11 December 2013 16:46:38 UTC