W3C home > Mailing lists > Public > www-style@w3.org > October 2016

[CSSWG] Minutes Telecon 2016-10-19 [css-text]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 19 Oct 2016 21:12:03 -0400
Message-ID: <CADhPm3ui2FQPhyS4+1ZQ6=iLLVx9VtCUw+B8x9EFr9gNtjOSSA@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Define effect of text-transform on copy/paste (Text Issue #108)

  - As a general principle there was a desire to have copy/paste
      match what users are seeing when they copy, however several
      people believed that the actual use cases in this case
      overrode the principle.
  - There were four main use cases that the group uncovered:
      1) Turning a heading into all caps
      2) Turning a first line into all caps
      3) Turning acronyms into small case when they're all caps in
         the source
      4) A ruby use case around ruby where in Japanese "じゃ" reads
         "sha", and "しや" reads "shiya". If that's your ruby, and
         there can be a text-transform to turn one into the other,
         because at small sizes it is hard to tell apart. But out of
         context, you don't want to change the pronunciation.
  - Though mostly in the above use cases preserving the
      text-transform would be the worse user experience, there are
      times where you would expect preservation.
  - Consistency between inner text, paste to plain text, and range
      to string was another thing to be considered in the decision.
  - In a straw poll the group was about evenly split between copied
      plain text ignoring text-transform or leaving it up to UA for
      UX decision.
  - Group members will look through browser bugs to try and
      determine user expectations.
  - There was also a desire to conduct a through user survey, though
      no one was tasked with creating one.
  - RESOLVED: White space property is applied to plain text paste

Interaction of hanging-punctuation and kerning (Text Issue #122)

  - RESOLVED: Don't define interaction between hanging punctuation
              and kerning and leave it up to UA to decide how to

Make hanging-punctuation scrollable overflow (Text Issue #123)

  - fantasai will write up her proposal for review as there wasn't
      time on the call.


Agenda: https://lists.w3.org/Archives/Public/www-style/2016Oct/0102.html

  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Tony Graham
  Koji Ishii
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Simon Pieters
  Anton Prowse
  Liam Quin
  Florian Rivoal
  Geoffrey Sneddon
  Alan Stearns
  Greg Whitworth

  Rachel Andrew
  Rossen Atanassov
  Daniel Glazman
  Jen Simmons
  Lea Verou

Scribe: dael

CSS Text

  astearns: Let's get started.
  astearns: Does anyone have any extra items?

Define effect of text-transform on copy/paste (Issue #108)

  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Apr/0015.html
  fantasai: I think there was a later agenda item which was the same.
  astearns: I was wondering
  <astearns> https://lists.w3.org/Archives/Public/public-editing-tf/2016Apr/0005.html

  <dbaron> presumably this is talking about plaintext copy/paste
           rather than HTML?
  <tantek> this is a long-standing debate
  <tantek> as long as I can remember in the WG :)

  fantasai: It's if text-transforms are preserved in copy/paste.
            This got into a larger issue as to what is preserved on
            copy/paste. The second URL is a proposal that you take
            the source text and the only things CSS effects are
            display property, content property and possibly
            visibility. Text-transform has no effect, you take
  fantasai: The argument for is text-transforms are done stylistic
            capitalization. So you capitalize an entire heading. It
            doesn't affect how content is used. If you use font
            transformation that shouldn't make a difference.
  fantasai: Also ruby transformation is loss-y. It can change the
            meaning of the word. We definitely want source text.
  fantasai: Proposal is add text that says what is used as plain
            text. If you're doing computation for rich text you'll
            take info from HTML and I'm not proposing we define that.
  <tantek> also ellipsed text should be copied!
  <tantek> that is, text-overflow should not stop text from being

  myles: My concerns are about usage for text-transform. When a user
         does copy/paste almost all users don't have knowledge of
         distinction between dom and style. They'll expect to see
         what they're seeing on the screen.
  Florian: I'd say that if they're copy/pasting something in caps in
           the middle of a legal document that should be in the
           source. If you have the first line as caps from a
           transform and you paste into a smaller line it will work
  * fantasai agrees 100% with Florian
  myles: The difference is text-transform is used across the web
         today. We have to work with the web we've got. Saying
         authors should style differently doesn't work on existent.
  Florian: If people use all caps for a title how is that different
           from text-transform?
  myles: Text only copy-paste you can't preserve.

  <gregwhitworth> so, in this example:
  <gregwhitworth> what does everyone do?
  <zcorpan> gregwhitworth, safari/chrome/opera copy uppercase;
            firefox copies original DOM case
  <gregwhitworth> yep, Edge does the same as everyone else
  <gregwhitworth> FF is the only one not copying

  tantek: I think conceptually I'd start with a similar approach to
         myles. There's a sense of user expectation where if they see
         something they expect that. That's clear with things like
         copying a list.
  tantek: The problem happens when you look at actual uses of
          text-transform. The most frequent use case I've seen is
          turning a heading or a first line all caps. In both of
          those cases the effect is less than what's desired.
  tantek: What I've seen in the heading cases it's a style effect
          that works on the page but when copied into plain text it
          doesn't look right. I find authors have used titlecase in
          their source content. So when you copy/paste you get the
  <ChrisL> Yes, I am pleasantly surprised when copy and paste on a
           title does not give me ALL CAPS
  <fantasai> tantek, yes totally made sense :) Thanks for great
  tantek: While I agree in principle once you look at specific
          examples you get a better effect when you don't copy the
          transform. I don't know how to further analyze. But I find
          the specific case trumps the general principle, but that
          doesn't preclude the general principle in other cases.
  astearns: myles do you find that convincing?

  myles: I guess...does anyone else have an opinion?
  <dauwhe> I've wasted much of my life fixing all-caps text.
  gregwhitworth: Everyone matches except FF. Is there a reason to
                 make the rest of us change? Is there outcry?
  tantek: With FF we think it's higher fidelity. I think that's why
          we did it. But I can't speak for other browsers.
  ChrisL: I think it was designed that way. I'm always pleased when
          I copy and the all caps becomes a titlecase. What we're
          asking for is we want to know what users want without a
          user study.
  gregwhitworth: I think it's important to understand user want. I
                 just don't want to create more work without a
  <Bert> (In my personal experience, I always wanted the original,
         lowercase, but I haven't studied the use cases.)

  <zcorpan> I'll note that .innerText applies text-transform. it's
            not necessarily the same as plain-text copy but still
  <johanneswilm> if you create an editor, you need to handle paste
                 anyway. and so it would be good if the browsers
                 provide somewhat similar html/inline-styles

  tantek: That's another approach where we could leave it undefined
          and see where it goes. Also, if you find other examples
          for text-transform I'm interested in analyzing them.
  fantasai: Another example is for acronyms where they're upper in
            the source but if you want small case you do
            text-transform: lowercase and font variant small caps.
            If you copy that with the transform you'd get your
            acronyms in small case.
  tantek: Does Chrome or Opera do that?
  fantasai: You'd have to find a page that's using small case for
            acronyms. I haven't run a test on this. Whatever browser
            preserves the text-transform will give you the lower
            case. When you have the font it looks right, but when
            you copy it out you lose the font.
  fantasai: That seems like a reasonable thing to do.
  tantek: I'd like to see a test to verify that. I wouldn't assume
          browsers are doing the right thing. They may have a hack
          to fix that up.
  <gregwhitworth> http://jsbin.com/jaziqelifo/edit?html,css,output
  <gregwhitworth> Edge preserves it
  <dauwhe> Chrome is returning lowercased text
  <tantek> gregwhitworth: you need to put "world" as "WORLD" in the
  <tantek> otherwise the text-transform has no effect
  <tantek> or use the actual noted example "HTML"
  <zcorpan> test case
            - lowercase in opera/chrome/safari
  <Bert> (Seems Webkit-based browsers return the abbrev *after*
         transforming to lowercase, Presto and Gecko return the
         original, uppercase)
  <fantasai> thanks, Bert
  <tantek> sounds like webkit et al then illustrate the bug of
           transforming an acronym to lowercase then
  <tantek> ok I'm convinced

  fantasai: If you make all small caps into text that would give you
            very broken behavior. I can run a test case, but my
            point is that's a case where you want the source text.
            That's only appropriate where you can choose a font.
  fantasai: Another use case if the Ruby transformation where if you
            use full size kana and you copy it out you've lost the
            distinction between small and large kana.
  fantasai: When you present them as the same size it's totally
            inappropriate. IF you're trying to copy just the ruby
            text you change the meaning of the word in some cases.
  fantasai: That's another case where text-transform shouldn't be
            preserved on moving to plain text.
  <Florian> to illustrate the ruby story, In Japanese "じゃ" reads
            "sha", and "しや" reads "shiya". If that's your ruby, and
            there can be a text-transform to turn one into the
            other, because at small sizes it is hard to tell apart.
            But out of context, you don't want to change the

  gregwhitworth: I think I want to go back to solid use cases. Where
                 Chris wants to preserve stuff paste as plain text.
  fantasai: That's the case we're talking about.
  ChrisL: We're not pasting and preserving style, It's where you're
          pasting plain text.
  gregwhitworth: Oh, okay.

  fantasai: So far we've given four specific use cases and all of
            them you want the text-transform to be dropped when
            pasting to plain text. If you think it should be where
            would it be more appropriate to preserve?
  <dauwhe> I want the non-transformed text
  fantasai: If someone thinks casing is important to preserve that
            should be in the DOM. And in most cases it would be in
            the DOM.
  koji: I think I'm with gregwhitworth where heading case the user
        expectation could be either way.
  koji: When you said DOM currently the text spec says we should
        apply transform. We share the plain text with [missed]
  koji: We share the plain text we inner text and rendered. [missed]
        Consistency there would be great.
  astearns: I think I heard koji says we should have consistency
            between inner text, paste to plain text, and range to

  <tantek> I think reasoning by specific examples trumps the
           reasoning by general principles in theory. Theory is a
           good place to start, but the specific examples provide
           much stronger bases for conclusions.

  dauwhe: This is something I run into all the time. I've wasted
          half my life trying to un-capitalize things from the web.
          We use the proper casing and transforms for effects but
          when I paste I want the untransformed.
  * BradK came in late, but agrees with what fantasai was saying,
          and has long disagreed with all-caps copying based on
  <tantek> I agree with dauwhe, uncapitalizing things is a massive
  koji: It varies by how you're using pasted results. You're using
        it as a source. If people want plain text to be the same the
        text-transform should be applied. I think there's both cases.
  Florian: I think it's tricky. In the copy/paste story there's a
           million variations where you want to preserve here and
           not there. I don't think we're looking at doing a million
           different options. If we're saying plain text is plain
           text we should keep it simple. Which is don't apply the
  Florian: There are cases where you want text-transform, but this
           is starting to look for where you want markdown.

  <bkardell> ChrisL: the results of that on twitter so far are
             surprising to me
  <bkardell> Is this something that we should be consulting people
             who are not in this WG?
  <ChrisL> https://twitter.com/svgeesus/status/788776037098385413
  <bkardell> current results on that twitter poll are almost 50-50
             consistently between a) and c)

  <tantek> I have yet to hear a single concrete example where
           copying ALL CAPS done via text-transform actually
           provides a better UX
  <tantek> so that's my question to the folks advocating for that
  <tantek> Where are the specific examples where applying
           text-transform is *helpful* to the user?
  <tantek> BTW UX design by "consistency with programming" is a
           HORRIBLE way to do UX design

  astearns: I'm hearing most people argue for not applying, but
            there is a block of people that want consistency with
            inner text or that what you see when you copy is what
            you get when you paste.
  astearns: I'm not hearing overwhelming consensus.
  astearns: We could leave things unspecified and let the browsers
            decide how to deal with this user action. That's
            something the browsers can complete on giving the
            experience their users want.
  <Bert> (Sometimes I want to copy-paste the generated list numbers,
         but not the uppercase...)
  fantasai: I hear people want consistency. Authors want
            consistency. I think this is a problem we want to solve.
            I think tantek question to people wanting it to apply
            hasn't been answered.
  fantasai: He asked that the people on the other side have provided
            arguments on implementation side and coding level side,
            but as far as user facing examples there have not
            provided a concrete example.
  Florian: koji said for headings you could argue on which way users
  tantek: I think there's 2 strong examples. I think both I and
          dauwhe mentioned that when you have to uncapitalize a
          heading from copy it's a massive pain. I haven't heard a
          single person want all caps.
  astearns: What I heard from myles is users want to paste what they
            see in the browser.
  Florian: In what scenario? In the heading I agree with dauwhe and
           tantek but I could see the other side. In the other
           stories not really.
  <johanneswilm> as long as there is a html version, you can always
                 create your own plaintext version following either
                 logic in the app that handles the paste. The
                 important part is that nothing is stripped in the
                 html version on copy.

  tantek: I think myles principle is the right starting point. When
          you dig deeper and look for specifics I think that trumps
          the general principle. Data wins over theory.
  dauwhe: And text-transform is lossy
  tantek: Yes. If it's title case and transformed you lose
  dauwhe: Yes, and sometimes it's hard to restore.
  koji: If you copy and preserve information as HTML it's not lost.
  dauwhe: But we're talking losing meaning
  dauwhe: It can sometimes take a skilled editor, at least in
          English, to restore original capitalization
  <ChrisL> Good point about it being lossy
  <ChrisL> But also good point about plain text losing any inline
           attributes, language changes, etc
  koji: If author used capital for information purposes it seems
  <BradK> If it is semantics, it should be in the source
  dauwhe: I think that's a less common case. I don't have data, but
          we see a huge number of headings. But the web has lots of
          other ways of indicating emphasis.
  koji: In terms of data if it's that big of a pain then 3 browsers
        should have received user feedback. I don't think we have
        that kind of feedback.
  <tantek> perhaps we need a straw poll for copied plain text: A
           ignore text-transform, B apply text-transform, C leave it
           up to UA for UX decision

  astearns: I'm not sure stories from people on the call that's not
            what we should base it on.
  <gregwhitworth> I agree with Alan
  ChrisL: I put a poll on twitter.
  <fantasai> ChrisL, your poll is limited in scope.
  bkardell: I think it would be worth constructing a good poll with
            actual examples and have everyone in the group promote
  bkardell: It's really interesting that so far it's been 50/50 on
            Chris's poll.
  fantasai: I'll point out that's the case with the most ambiguity.
            Other cases we brought up you would see a much stronger
  bkardell: Right, and a really good poll would capture those.
  astearns: Koji asserted that the browsers not doing it have
            received feedback. I'm not sure this will be a minor
            bug. It might be good to look at the bug databases.
  tantek: dauwhe just brought it up.
  dauwhe: I'll go file bugs. It makes my life miserable.
  <dauwhe> not Amazon-level misery, to be honest :)
  <bkardell> but would people even open that with a browser - a lot
             of people wouldn't know if that was OS level or browser
             level or what
  <BradK> suspects it has been reported as a bug already
  <gregwhitworth> Make sure to point at the spec
  <fantasai> gregwhitworth, there is no spec, that's the point
  <gregwhitworth> fantasai: that was my point :)
  <gregwhitworth> he can file bugs, but if there is no spec - we
                  won't be changing just for the sake of changing

  astearns: Let's collect more data. I like the idea of a straw poll
            to see what this current small group thinks at the
  Florian: I have a bit of a question. When you have screen readers,
           do we expect they operate on the same text basis as we're
           talking at here?
  tantek: They're looking at markup, so it's totally different.

  astearns: Straw poll in IRC.
  <astearns> copied plain text: A ignore text-transform, B apply
             text-transform, C leave it up to UA for UX decision
  <BradK> A
  <ChrisL> A
  <dauwhe> A
  <fantasai> A
  <Florian> A
  <johanneswilm> A
  <tantek> A, can live with C
  <zcorpan> C
  <astearns> A
  <gregwhitworth> C
  <fremy> C
  <myles> C
  <koji> B or C
  <TabAtkins> C, fine with A
  <Bert> C, 2nd choice A
  <bkardell> A but would really like to not have a decision in this
             room without a better study of people outside the room
  <gsnedders> B or C
  <smfr> A or C
  <liam> C if the browsers might actually implement a Copy Special
         (seems unlikely)
  astearns: This straw polls is to get a sense of where we are. We
            need additional data.
  <ChrisL> @bkardell yes we need way more data from people who are
           not us
  <ChrisL> we can see that B was not at all popular, though
  <bkardell> ChrisL indeed - that was interesting

  <dauwhe> there seems to be some correlation with browser people vs
           non-browser people
  <Florian> dauwhe: I think this last comment of yours is worth
            having on the record

  astearns: It looks about 50/50 between A and C.
  astearns: Lets collect more data, but at the moment I'm not seeing
            a warranted spec change.
  <gsnedders> I think as soon as we phrase it as involving
              text-transform we're cutting out many people's
  <gsnedders> And many of the people we should be listening to most
  fantasai: I'd like to know who is collecting the data. If they're
            talking about just headings or more cases. And I'll note
            people have asked for interop. I understand C might be
            great if a browser would allow a preference, but if
            there isn't a preference it seems it would be good for
            us to settle on an answer.
  tantek: There's a preference. You switch browsers :D

  <bkardell> can we take an action item for a few people to design a
             post/poll that we can get feedback from the group on
             before posting?

  koji: I think the data is not use cases, but data from user
        feedback and bug DB.
  astearns: koji will look at Blink bug base.
  gregwhitworth: I'm scrolling through Edge. Based on the use cases
                 you provided I think we should focus on things
                 where what I saw and pasted seems broken. Cases
                 that inform what the user wants. Do you want
                 everything I'm finding or just the specific
  astearns: I think we should look for bugs on plain text paste.
  gregwhitworth: Most of these are text format because they're going
                 into word. If I find it I'll share pending privacy
  Florian: This is the kind of edge case because where it's not
           clear if the user will be annoyed at the browser or at
           where they're pasting.
  <ChrisL> good point, florian
  <dbaron> People are more likely to know there's something with the
           browser if they see something different on paste than
           they do in the browser
  gregwhitworth: We're all in the same DB, so Word will give them to
                 us when it's us. I'm not sure about FF and Chrome,
                 but I suspect the word editors do share with
  tantek: I'm curious to see what gregwhitworth comes up with.
  <dbaron> (I think there is a bug in bugzilla.)
  Florian: I am too. But if there's nothing in the bug DB I think
           this is just an indicator that this is obscure.
  <zcorpan> https://bugs.chromium.org/p/chromium/issues/list?can=2&q=copy+text-transform&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids
  <BradK> https://bugs.webkit.org/show_bug.cgi?id=43202
  <zcorpan> https://bugs.chromium.org/p/chromium/issues/detail?id=325231
  <dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=35148

  tantek: This is the tip of a very large iceberg. I remember taking
          up hours and hours of time 18 years ago. We won't solve it
          on one telecon. I encourage people to look up bugs on copy/
          paste because it'll be inconsistent a lot.
  myles: I'll look at webkit bug base
  astearns: Can someone look through FF bug base?
  dauwhe: I guess I can look there.

  <gregwhitworth> fantasai: what is the timeframe for this, I like
                  to put actions on my calendar and I work best with
  <fantasai> gregwhitworth: Novemberish?

  fantasai: On the copy/paste topic, one of the things that should
            affect plain text output is the white-space. Is anyone
            arguing it should not?
  astearns: Is white space a separate issue?
  fantasai: It's part of the issue.
  fantasai: But it could be separated out. They don't have to be the

  koji: I think the consistency with innerText is something JS
        editors can use and innerText says apply white-space so I'm
        fine to apply it.
  astearns: So that's one opinion that white space collapsing should
            be preserved.
  <liam> +1 preserve
  <liam> i.e. apply
  <dauwhe> +1 apply
  <Florian> no disagreement from me, apply it.
  fantasai: And I agree. Does anyone disagree with preserving white
            space transformation?

  astearns: We could resolve that plain text pasting preserves white
            space collapsing.
  <tantek> AND when white-space pre-wrap etc., preserve that too
  astearns: Objections?
  tantek: Modification. Not just collapsing, but white space
  astearns: Okay, white space property is applied to plain text
            paste output.
  <dbaron> Is that what implementations do?
  <dbaron> (or do they just always do whitespace collapsing?)

  RESOLVED: White space property is applied to plain text paste

  koji: Which spec is this added to? Text 3 or 4?
  <fantasai> CSS3 Text
  astearns: 3. This is issues in test 3 DoC

  dbaron: Is that what impl actually do?
  <gregwhitworth> based on a quick test, Edge does keep in plain
                  text the white-space settings
  <fantasai> FF does
  astearns: Edge does.
  gregwhitworth: I just tested a white-space:pre-wrap.
  <gregwhitworth> https://developer.mozilla.org/en-US/docs/Web/CSS/white-space
  <fantasai> Chrome also does
  <koji> looks like Blink collapses
  <Bert> (I think all browsers preserve white space when copied from
  <BradK> White-space: nowrap isn't preserved, is it? It isn't in
  <fantasai> Hm, no, I think it's just the collapsing that'd be
             preserved. Nowrap would involve transforming text,
             which is probably not desired
  <BradK> I take it back: even in plain text, nowrap is preserved.
          I'm surprised.
  <BradK> Nope, I fooled myself. Nowrap is not preserved in
          plaintext paste from Safari.

  Florian: Copy/paste code would be horrible if we didn't do that.
  Florian: If you copy/paste a piece of code with line breaks in the
  gregwhitworth: As we always said we can un-resolve, but I think we
                 should try and do everything in this area.
  myles: Webkit honors what the whitespace property describes.

  tantek: Another example where we're saying the user does not get
          what they're seeing is text-overflow which is speced in
          CSS UI where it says selecting the ellipsis you copy the
          ellipsed text. So that says text overflow doesn't effect
          copy/paste of plain text.
  <fantasai> tantek, I think you already have that
  <tantek> https://www.w3.org/TR/css-ui-3/#propdef-text-overflow

  <zcorpan> https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute
            is the spec for innerText btw. "The CSS 'white-space'
            processing rules are slightly modified: collapsible
            spaces at the end of lines are always collapsed, but
            they are only removed if the line is the last line of
            the block, or it ends with a br element. Soft hyphens
            should be preserved. "

  astearns: I have a feeling that a number of issues with copy/paste
            will be quite a bit of work to get interop. To get L3 of
            text done we may punt to 4.
  Florian: What tantek mentioned isn't in CSS 3 Text. Only the
           copy/paste for text properties need to be defined in it.
  astearns: That's fair.
  astearns: In any case, I think 50 minutes is enough today.

Interaction of hanging-punctuation and kerning (Issue 122)

  fantasai: Question was about what happens if you have kerning
            between hanging punctuation character and the subsequent
            character. It's not a problem in CJK typography but
            happens when you have a " and an A. Do you push the " to
            hang left or do you pull it with the A?
  fantasai: I don't have an answer.

  dauwhe: I've been looking at this in inDesign and as far as I can
          tell it has a fixed position for the hanging character and
          that doesn't move regardless of the next letter, but it
          will change the position of the next letter. So the A will
          move somewhat but the " stays.
  <liam> https://lists.w3.org/Archives/Public/www-style/2016Mar/0074.html
         may be helpful here, from John Hudson

  Florian: Can we action someone from Adobe to see if this is
           something people are happy about?
  astearns: I know this is the expected behavior from customers I've
            talked to. I'm basing my intuition on the implementation
            dauwhe described.
  Florian: But people aren't complaining.
  dauwhe: Punctuation doesn't hang entirely out, it's only about 2/3
  liam: Theory is you're making an optical vertical line of the
        margin and the punctuation is a little fly on the edge. The
        kerning brings the punctuation in a little closed to the A
        is inline.
  Florian: So you're saying opposite?
  astearns: And the message from liam says that too.
  myles: Is this a place where introp is critical? It seems that
         browsers could kern differently and that's not so bad.
  dauwhe: That seems plausable to me.
  liam: I think impl would benefit from guidance rather than needing

  myles: We don't need a resolution for guidance.
  fantasai: The spec is at a point where any guidance effecting impl
            needs consent of WG. Nicer examples I don't need
            permission, but any guidance affects implementation.
  <tantek> I think I need to see pictures.
  <tantek> preferably of book typography
  Florian: I'm leaning undefined in level 3.
  astearns: That's where I'm leaning. Since we have opposed opinions
            I don't think it makes sense to define it.
  fantasai: Works for me.

  dauwhe: fantasai do you want a picture of inDesign?
  fantasai: Sure
  <tantek> send pics to the list!
  fantasai: If you would like to add illustrations to the spec
            please go ahead.
  Florian: Be careful of how you add the illustration if we're not
           defining it.
  <liam> would like to see the example
  <tantek> dauwhe - perhaps post illustrations to www-style first?

  astearns: So do we need a resolution saying not going to define?
  Florian: I think so.
  astearns: Proposed resolution: don't define interaction between
            hanging punctuation and kerning and leave it up to UA to
            decide how to adjust.

  RESOLVED: Don't define interaction between hanging punctuation and
            kerning and leave it up to UA to decide how to adjust.

Make hanging-punctuation scrollable overflow (Issue 123)

  fantasai: We had resolved hanging punctuation is ink overflow, he
            preferred scrollable. Florian pointed out a lot of CJK
            glyphs only take half the glyph space and author may
            have made that ignored overflow. That half would be ink
            overflow and the other half scrollable but that's weird
  fantasai: We can say the hanging punctuation are scrollable but
            for CJK characters that would get trimmed in text
            spacing property they maybe trim at end of the line if
            punctuation hanging.
  Florian: If you're going this way I don't want maybe trim, I want
           must. That will let the author predict if they're getting
           a scrollbar.
  fantasai: I think because text spacing isn't in this level of the
            spec I think I would insist on a may for this level.
  Florian: Should?

  fantasai: The layout won't change based on this distinction other
            than the presence of a scroll bar.
  Florian: But having a scrollbar in some browsers is terrible.
  fantasai: It's that or all of it. You can only trim in certain
            fonts. Some Chinese will place punctuation in middle of
            glyph. This is not a simple issue.
  astearns: We're out of time. fantasai can I ask you to put your
            proposal in github or on ML so we have on thing to talk
            about and give people some time to take a look?
  fantasai: Yep.
  astearns: Okay. I think we're done for the day. Thanks everybody.
Received on Thursday, 20 October 2016 01:13:11 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:01 UTC