Re: Issue-286: application of padding to p etc

Regarding the padding on rendered lines:
I think that the desired behaviour can be illustrated with the new 
pseudo-element ::first-line pseudo-element [1][2]. Although it only 
targets one specific line of a "block-container box" (obviously the 
first) it shows how style attributes are applied to a line that is 
rendered by the client instead of a line that is marked up already by 
the author (e.g. through the use of spans).

At http://jsbin.com/iCIKUKuJ/3/edit you can see some examples that show 
the use of "::first-line". There are three paragraphs with the same 
content and style. They only vary in the width of the p element. The 
first has the width of 100px, the second a width of 250px and the third 
p element has an unbounded width (so it is limited by the container 
where it is contained in).

You can see how the style attributes defined for the "p:first-line 
selektor" (black background and yellow text) apply only to the first 
line content and how the selected content changes according to the width 
of the p. The red border marks the size of the p block container. If you 
change the size of your browser window you can see how the first line 
styles adopt dynamically to the changed rendering of lines.

So what can be derived for TTML to meet the requirement of "line-padding"?

1) In CSS only the first line can be addressed. In TTML all lines of a 
block container should be “selectable”. To make a mapping as easy as 
possible CSS has possibly to be extended with a new pseudo element (e.g. 
with a ::lines pseudo element).

2) The issue where the discussion started was padding on lines. So there 
maybe a new attribute in TTML (e.g. "linePadding") to add this 
functionality. This applies to (at least) the start and end edges of all 
"lines" in a block-container and can specified to at least the p element 
(although body, div and region could be included as well.) This 
attribute is not inheritable.

3) If there is already the conceptual model of a "line" then why not 
apply background to the lines as well. It would work the same as for 
::first-line. All concepts for inheritance and the precedence of 
background application already exists.

Best regards,

Andreas

[1] http://www.w3schools.com/cssref/sel_firstline.asp
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/::first-line

Am 06.12.2013 00:25, schrieb Glenn Adams:
>
>
> On Fri, Dec 6, 2013 at 1:25 AM, Nigel Megitt <nigel.megitt@bbc.co.uk 
> <mailto:nigel.megitt@bbc.co.uk>> wrote:
>
>     Hi Glenn,
>
>     I've had a look at your edit that added padding to content
>     elements and I don't believe that this contradicts the usage
>     defined by EBU-TT-D in Issue-286 as written. However we need to
>     describe exactly what padding means when applied to body, div and
>     span, assuming the EBU proposal for the definition on p carries.
>
>     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
>
>
>     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
>
>
>     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
>
>
>     span: applies to the contained text within the span.
>
>
> more accurately, applies to the inline areas (boxes) generated by span
>
>     Adds to or overrides p-based tts:padding values?
>
>
> padding on p and spans are treated separately and independentlty
>
>     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
>
>     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.
>
>     Kind regards,
>
>     Nigel
>
>     ----------------------------
>
>     http://www.bbc.co.uk <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.
>
>     ---------------------
>
>


-- 
------------------------------------------------
Andreas Tai
Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH
R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
Floriansmuehlstrasse 60, D-80939 Munich, Germany

Phone: +49 89 32399-389 | Fax: +49 89 32399-200
http: www.irt.de | Email: tai@irt.de
------------------------------------------------

registration court&  managing director:
Munich Commercial, RegNo. B 5191
Dr. Klaus Illgner-Fehns
------------------------------------------------