- From: Andreas Tai <tai@irt.de>
- Date: Tue, 10 Jan 2017 19:30:26 +0100
- To: Pierre-Anthony Lemieux <pal@sandflow.com>, "public-tt@w3.org" <public-tt@w3.org>
Hi Pierre, Thanks for posting this! Very interesting! This means when using "xml:space=default" you may have to apply a "normalize space" function on the string before mapping it to HTML. Best, Andreas Am 10.01.2017 um 05:52 schrieb Pierre-Anthony Lemieux: > HI all, > > FYI. See below discussion below on the CSS reflector re: treatment of > white-space at line break in Chrome and Edge. > > There is currently a strange behavior where white-spaces are > suppressed after the line break but not before the line break. > > Looks like an implementation bug, as a result of which there is > currently no equivalent to the TTML xml:space=default in these UAs. > > Best, > > -- Pierre > > > ---------- Forwarded message ---------- > From: Pierre-Anthony Lemieux <pal@sandflow.com> > Date: Mon, Jan 9, 2017 at 8:44 PM > Subject: Re: [css-text] Collapsing whitespace at the end of a line > To: fantasai <fantasai.lists@inkedblade.net>, "Tab Atkins Jr." > <jackalmage@gmail.com> > Cc: www-style list <www-style@w3.org> > > >> Why preserve the space before the break but not after it? o_O > I ran into this bizarre behavior issue while working on subtitle > rendering. See top example at: > > https://codepen.io/palemieux/pen/bgVJKO > > The space before the line break remains, but not the one after. > > I would think this is an implementation bug, unless there is a > historical reason. > >> Well, sure, but wouldn't you want pre-wrap for those kinds of cases? > Yes. Any downsides to pre-wrap? > > Best, > > -- Pierre > > On Sat, Jan 7, 2017 at 8:21 PM, fantasai <fantasai.lists@inkedblade.net> wrote: >> On 08/19/2016 07:23 PM, Tab Atkins Jr. wrote: >>> On Wed, Aug 17, 2016 at 7:19 PM, fantasai <fantasai.lists@inkedblade.net> >>> wrote: >>>> On 09/10/2015 01:36 PM, Tab Atkins Jr. wrote: >>>>> >>>>> According to <https://drafts.csswg.org/css-text/#collapse>, whitespace >>>>> preceding a segment break is removed. However, it appears that >>>>> browsers instead collapse it to one space. >>>>> >>>>> Here's an example using 'white-space': >>>>> >>>>> <div style="white-space: pre-line;">a >>>>> z</div> >>>>> >>>>> (Just in case the email client trims things, there's a space at the >>>>> end of the first line, after the "a".) >>>>> >>>>> Here's an example using <br>: >>>>> >>>>> <div style="white-space: pre-line;">a <br>z</div> >>>>> >>>>> In both of these examples, if you highlight the "a" and then drag >>>>> slightly rightward, you'll see it highlight a space character as well. >>>>> This happens in both Chrome and Firefox. >>>>> >>>>> This sgugests that browsers are not following the "preceding" part of >>>>> step 1 in that section, and are instead falling down to step 4, where >>>>> runs of spaces are collapsed down to a single visible space. >>>>> >>>>> Is there a particular reason for this? Should we adjust the spec to >>>>> match implementations, or file bugs on implementations to match the >>>>> spec? >>>> >>>> I'm inclined to file bugs on implementations to match the spec, >>>> since that seems like kinda weird behavior. Why preserve the >>>> space before the break but not after it? o_O >>> >>> I don't particularly care either way, tho there are cases where >>> trailing whitespace has some significance - for example, illustrating >>> markdown examples (where two trailing spaces indicates a hard >>> linebreak). >> >> Well, sure, but wouldn't you want pre-wrap for those kinds of cases? >> >> [Testcase attached, fwiw.] >> >> ~fantasai -- ------------------------------------------------ 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 ------------------------------------------------
Received on Tuesday, 10 January 2017 18:58:12 UTC