[CSSWG] Minutes Sydney F2F 2016-02-03 Part III: SVG Text Issues

=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


SVG Text Issues
---------------

  - The group went through a list of issues and problems that Tav
      has documented here: http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/
  - Discussed using exclusions to help handle SVG shapes
  - It was noted that shape-inside doesn't have an equivalent
      functionality to wrap-flow (which says which side of the shape
      to fill); this is needed to handle filling concave shapes
  - Discussed ideas for sequentially filling shapes
  - Need to clarify that line boxes are fitted to nonrectangular
      shapes by requiring zero intersection.

  - Middle (half of the x height) and Alignment (synonym for text
      top and text bottom) baselines may be useful to add to CSS
      Inline.
  - It may be preferable to have the baseline table reset when the
      baseline font changes - this would be a behavior change from
      SVG 1.1.
  - SVG origin for coordinates isn't changed by values from text
      orientation.
  - A decision on default values for mathematical values will wait
      for more data.

===== FULL MINUTES BELOW ======

Agenda: https://wiki.CSSwg.org/planning/sydney-2016

Scribe: alancutter & nainar

SVG text issues
===============

  Tav: Let me paste a link.
  <Tav> http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/
  Tav: I have a whole series of issues with trying to finalize SVG
       text.
  Tav: Maybe I should go through how SVG text differs from CSS text.

Auto-wrapped text
-----------------

  Tav: I have two diagrams there.
  Tav: For HTML you have an absolute size and right flow left
  Tav: float right float left using shape outside property you can
       cut out regions - you end up with a region you can fill.
  Tav: You can cut out regions and have a region that you fill which
       is the blue line region.
  Tav: In SVG we don't have floats - have a text element
  Tav: because we don't have floats you can have a shape outside
       that you exclude.
  Tav: Once you get to that point everything that works for CSS
       should work for SVG.
  Tav: We in the SVG group have discussed at what level do we
       combine with CSS?
  astearns: One way to paper over the difference is to have
            shape-outside to apply to exclusions.
  astearns: Apply to exclude - 1st diagram could have instead of
            floats exclusions - map closer to SVG
  astearns: map closer to what we are trying to layout.

  fantasai: SVG provides some shape and you get a containing block.
  Tav: Yes, been my understanding...
  Tav: CSS just fills that makes sense to me.
  fantasai: Whether you think about that as a shape inside or a
            bunch of floats doesn't matter much.
  Tav: The spec only needs to deal with containing block and shape.

  Tav: Right - a few issues
  Tav: In html a float on one side - float right on the other side
  Tav: because the shape-outside applies to float...there is one
       shape per float.
  Tav: In SVG have a float on each side so you can exclude values.
  AmeliaBR: The exclusion spec would do this
  AmeliaBR: but its not using the syntax you have here.
  AmeliaBR: shape-outside is applied to the element that interrupts
            the flow not the shape below.
  AmeliaBR: With CSS exclusions it could be made consistent.
  AmeliaBR: Depends whether SVG wants to go ahead with ways to do
            the exclusions or ???
  astearns: I would qualify the status of the spec as waiting
            implementer interest beyond the first implementation.
  astearns: Better if SVG forges on.

  Tav: Get back to we are wrapped text
  Tav: relies on a lot of modules
  Tav: how to layout the top line?
  Tav: Not just SVG issue - you can with floats and now with round
       display.
  Tav: You can have a non straight edge.
  Tav: What do you do ... move down a few steps.
  fantasai: Yes that's how normal floats work.
  fantasai: It's not fantastic but that's how normal floats work ....
            there's no baseline grid.
  Tav: I saw there was a spec - line width? may be solution
  Tav: Slide down till you fit something in.

  Tav: Next question how to handle overflow - natural way of
       expanding.
  Tav: A good solution would be to expose the text somehow
  Tav: by clicking on ellipsis on end - eg
  Tav: or a tooltip appear
  Tav: in shapes too you continue underneath rectangular area.
  Tav: Covering up other content..
  astearns: That's the general situation for overflow:
            it covers up other content.
  astearns: I like your overflow tooltip to add.
  astearns: The basic case should be what CSS does with their
            defined boxes.
  astearns: It overflows in the direction.
  <astearns> though whiffing in overflow situations seems appropriate

How to handle shapes with doughnut holes, etc.?
-----------------------------------------------

  Tav: OK, we don't have a block content - we could fake it
  Tav: using the width?
  Tav: How to handle shapes like doughnut holes?
  Tav: The SVG 2.1 spec had
  Tav: kind of looks like a lot squeezed in the middle.
  astearns: Is this the same link?
  <Tav> http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/
  <heycam> we are now looking at section 3.3
  Tav: Same link here.
  Tav: Same discussion that wrap flow property not appropriate in
       this situation.
  Tav: Limit text to one side or other side.
  Tav: To start what is shown there is the proper thing to do...
  Tav: in the future add another property.
  <AmeliaBR> I've written up some comments here, too. Possible new
             property:
https://github.com/w3c/SVGwg/issues/37#issuecomment-178850020

  astearns: I'm not sure I understand... looking at fig 11?
  Tav: Yes, is there a problem with the way its filled
  Tav: broken up into L/R side.
  astearns: Right, we did talk a bit about this yesterday where
            we're going to tighten up the spec to say in these cases
            the lines are broken up into separate line boxes.
  Tav: Yes.
  Tav: and are placed in the order determined by the writing mode.
  Tav: Yeah I agree with you.
  Tav: Probably not what anyone would want to do.
  Tav: But thats a behavior you should do.
  astearns: That's my expectation.

  AmeliaBR: I agree that it's not ideal especially when fitting text
            to an SVG shape.
  AmeliaBR: One suggestion: add a property that by default is the
            behavior ... continue on in a straight line
  AmeliaBR: Stand across the line and put text in that or ..
            interruption ...
  AmeliaBR: The wrap-flow property has different applications and
            different values that can control wrapping outside a
            solution region...
  AmeliaBR: Here we're talking about an arbitrary shape.
  astearns: Already have wrap-flow max and min.
  astearns: You are correct there is something called wrap-flow fill
            - we can add that you are correct.
  astearns: Sure.
  Tav: I don't see that as high priority but something maybe for the
       future.
  AmeliaBR: Couldn't be the same wrap-flow property, it's the
            difference between shape-inside and shape-outside.
  AmeliaBR: Talking here about what happens inside a shape-inside
            property.
  AmeliaBR: It would be parallel ..
  AmeliaBR: As long as there's a clearly defined default behavior.
  astearns: I see your point - we don't have the max and min for the
            shape-inside - can be added

Sequential Shapes
-----------------

  Tav: Moving on - next topic - question on how to fill sequential
       into multiple shape.
  Tav: this was something in SVG 1.2
  Tav: I would like to be able to preserve that.
  Tav: At first CSS regions seems like a solution but I tried
       sitting down to mock up something but couldn't.
  Tav: The easiest way seems like have a shape inside and a list of
       URL references.
  Tav: You fill the first shape and if there's text left over you
       fill the next shape.
  astearns: Going by the named flow terminology - create a region
            with id - doesn't work for SVG purposes - what is in the
            region spec
  astearns: flow-from? Wouldn't get the list from ... we have talked
            of creating different region chains before.
  astearns: Have an element say what the next thing in the list is
  astearns: CSS mechanism if that doesn't work.
  Tav: Would a list shape inside and a list work?
  astearns: I suspect so - more flexibility - CSS gets order from
            document order, can't change.
  fantasai: You can use order.
  astearns: Took that out.

  AmeliaBR: The main difference is CSS regions assume there are
            elements in the document that provide
  AmeliaBR: While in SVG the shape wouldn't necessarily be text
            containers.
  AmeliaBR: Is there any objection to expanding shape-inside and
            should it be SVG specific or welcome in CSS shapes in
            general?
  AmeliaBR: Would not be the union but you spill across....
  astearns: I think if you are going to come up with a new mechanism
            for a region chain - should be SVG specific - rejected
            ways of constructing region chains in SVG.
  Tav: We would just define SVG shape-inside syntax for SVG purposes.
  astearns: I think so - that would be right way to start - merge
            later
  Tav: Okay.

  Tav: Same thing for shape-outside
  astearns: The shape outside - might be better to converge with how
            exclusions are created in CSS - nothing new needed to be
            added for SVG.
  Tav: I can take a look at that.
  shepazu: Is it that case that an implicit...
  shepazu: if you have a class on an element or selector ... you had
           one or several text elements.
  shepazu: You used the wrap selector it would fill them
           sequentially in document order?
  Tav: One text element that has all text.
  shepazu: What about there regions?
  Tav: Different regions are properties within that element -
       referenced in the region.
  shepazu: I see okay.
  Tav: In that case could the list be generated by the shape inside
       the element .. let's talk later.

  ed: I have a question about flow regions, is there a way to get a
      callback for when a flow region is full?
  astearns: Yes.
  astearns: To generate additional regions in script?
  astearns: In the region specification - specified there.

Fitting Glyphs to Nonrectangular Edges
--------------------------------------

  Tav: Ok.. the final item in this section
  Tav: How is the first glyph positioned and aligned - easiest thing
       is considering the embox height
  Tav: fit it against whatever edge you have.
  Tav: What if line-height of 2
  Tav: extend the box up and down - that's the box up against the
       edge.
  Tav: That's nowhere in CSS a spec.
  Tav: Understand what I'm asking?
  astearns: Catching up...this is fig 13?

  Tav: fig 13 - CSS inline spec
  Tav: Some gray boxes, assume they wouldn't be existent in our text
       wrapping - shape margin/padding at edge.
  fantasai: I think it's an alternate way of thinking about it, it's
            equivalent.
  astearns: The diagonal is misleading. Boxes don't exist, outline
            exists.
  Tav: I understand that.
  Tav: What part, the 'o' of voting.
  Tav: Assuming 'V' is giving the edge of the shape, how close does
       the 'o' get to the 'V'?
  astearns: Entire height of the line-box.
  astearns: As soon as any of it collides - it stops.
  Tav: Okay, I didn't see where that was specced in CSS?
  Tav: Check and make sure.
  Tav: Certainly line height - make clear in spec.
  Tav: Working same way as floats - shape had been replaced by 1 px
       tall floats how line box would fit against floats.

Additional Baselines
--------------------

  Tav: Okay. We can go back to baseline issues.
  Tav: Section two. Let's talk about dominant baseline.
  Tav: It shows the existing values of dominant-baseline in SVG and
       tests what different browsers are doing.
  Tav: The SVG dominant baseline is based on ? there's use-script ...
       text-before-edge.
  Tav: I'm not worried about losing use-script, I didn't test other
       browsers.
  Tav: Then there's reset-size that has a purpose that maybe CSS ...
       it's not needed.
  Tav: Is it possible to get ideographic and add it to CSS inline
       spec?
  AmeliaBR: It might be worth mentioning middle is in CSS inline not
            for dominant baseline.
  AmeliaBR: For alignment baseline - as synonym for text top and
            text bottom
  AmeliaBR: for SVG content - same can be done for dominant baseline.
  AmeliaBR: Also in most forms equal to ext after edge
  AmeliaBR: can also be added in a fall back synonym for fallback
            SVG synonym.

  fantasai: The list of baseline values that are in the spec are
            aggressively trimmed down. We have an open issue to
            check what's actually needed and add as necessary.
  Tav: In fonts - the baseline table.
  fantasai: Less clear what middle means.
  Tav: It's half of the x height.
  AmeliaBR: Middle is very useful in SVG - things look nicely in
            lower case text - center is good for upper case
            ideographical texts.
  fantasai: Okay.
  ACTION: fantasai add middle and ideographic baselines to
          dominant-baseline
  Tav: It would be great to get those two added.

Baseline Tables and Font Size Shifts
------------------------------------

  Tav: 2.1.3 is baseline table
  Tav: SVG 1.1 xll - on which SVG 1.1 is derived.
  Tav: The baseline table changes when baseline font changes.
  Tav: Looking at CSS inline spec it's not clear what expected
       behavior is.
  Tav: Tested browsers don't follow this.
  Tav: Browsers don't implement - follow - behavior in SVG 1.1 xll
  Tav: Change font size hanging glyphs hang from same point -
       alphabetic scripts - would be positioned along alphabetic
       baseline.
  fantasai: We're not doing that and that's an intentional change.
  fantasai: If we need a value that preserves baseline table,
            could add that, but need use cases.

  fantasai: You have a bunch of small text and text twice as big.
  fantasai: It doesn't make sense to have hanging baseline hand down.
  fantasai: Makes sense to reset instead.
  Tav: I was thinking about where it makes sense - make font 10%
       bigger to emphasize.
  fantasai: Alright.
  fantasai: The only a problem is if mixing script - strange to have
            baseline shift.
  fantasai: Would be strange to have it not shift.
  fantasai: Let me draw it.

  AmeliaBR: Related is to have CSS inline .. dominant baseline
            property.
  AmeliaBR: define dominant baseline that sets layout grid .. is not
            layout grid until set to explicit value.
  AmeliaBR: the fact that dominant baseline is inherit by default
  AmeliaBR: tab's issue .. you're always calculating it ...

  fantasai: Dominant baseline property inherits
  fantasai: baseline doesn't...
  fantasai: Small text big text in middle.
  fantasai: Take text to align to hanging baseline.
  fantasai: Sine if same size here - if same size here - expect it
            to go here.
  fantasai: Off-center - shift to bigger size.
  fantasai: Stuff of same size align together.
  fantasai: That's why we reformat baseline everytime font changes.

  Tav: Now do the opposite, make the things smaller.
  fantasai: <draws>
  fantasai: vs floating way up here - weird also.

  fantasai: Nesting structure - makes sense for content of same
            nesting structure should fit same nesting structure.
  fantasai: Parallel structure floats together: baseline table
            is maintained at parent's size.
  fantasai: But when nesting - each unit of text consistent with
            itself.
  fantasai: Thats why reformat baseline table when the font changes.
  fantasai: Mixed content aligns to single unit with respect to text

  Tav: I'm not sure I would expect that, if I had handing glyphs in
       the ABC I would expect the smaller text to match the ABC.
  fantasai: If you asked it to attach itself to a nesting element
  fantasai: If this is a sibling of that and the alignment is a
            sibling of the other
  fantasai: if this is a parent element with text inside it
  fantasai: then that intermediary element - will reset base element
            for all its kids.
  fantasai: If you aren't inside here use parent inline baseline
            table.

  SteveZ: So the difference arises when I have an element that is
          inside and have a hanging text in it.
  SteveZ: The small hanging text goes to the top the alphabetic text
  SteveZ: it's all going to be smaller and the alphabetic will all
          be at the bottom or all at the top.
  fantasai: No, actually that is not what happens.
  fantasai: Not about what element comes first.
  fantasai: If you decide you have a quote inside a p you have a
            quote with text in different language mixed in
  fantasai: If the quote's baseline table is sized differently -
            fit inconsistent size.
  Tav: That's what reset size value is supposed to do.
  fantasai: We reset by default - usually what you want

  SteveZ: We don't have a survey that says what you want.
  SteveZ: I think the point is that what the default value for
          resize is it's clear there's use cases that want to avoid
          resizing or explicitly do resizing.
  SteveZ: We could have a preserve value so that it doesn't change.
  SteveZ: That's just changing the default.

  fantasai: I mean if we look at single script - super/sub script -
            the script is not floating in line - in consistent
            position - I would expect similar structures to have
            same behavior.
  fantasai: No one has shown me a case where you want the preserve
            behavior.
  fantasai: Love to see examples outside of spec examples.

  Tav: Maybe it's not significant, it is a change in behavior from
       SVG1.1 though.
  fantasai: I mean if SVG needs behavior for compat...
  Tav: Maybe it is not needed. We still need to mention change in
       behavior.

  astearns: so.. is that about as far as we will get on this one.
  astearns: Let's take a 15 minute break.

  <br type=15 minutes>

  * fantasai just checked in definitions for ideographic and middle
             baseline values

text-orientation
----------------

  astearns: Let's get started again.
  astearns: tav you have a couple more issues?
  Tav: Okay the next issue: auto values for text-orientation.
  Tav: SVG has vertical values because there's Adobe content whose
       output can rotate the glyphs.
  Tav: The default baseline is alphabetic, in SVG1.1 the alignment
       baseline for vertical text was always central.
  Tav: Is is going to cause text from old Adobe products to shift a
       bit when there's text orientation 90 degrees.

  fantasai: So, we should fix this by defining that in SVG the origin
            for coordinates isn't changed by values from text
            orientation.
  fantasai: While dominate baseline may change
  fantasai: auto value of baseline may change
  fantasai: also causing SVG to recognize that origin point for
            coordinates doesn't change.
  Tav: Okay so that would be in the CSS, would take care of that.
  Tav: I think that would end up being a change to outline spec.
  Tav: Auto values that references auto mode - will also have this
       magic.
  Tav: Okay that sounds good.
  Tav: Where coordinate system doesn't change.

  <fantasai> Tav --
https://hg.csswg.org/drafts/diff/6384ffddc849/CSS-inline/Overview.bs ?

Default Values
--------------

  Tav: The next issue is default values for where the baseline should
       be if the font does not specify it.
  Tav: Default values for mathematical values.
  Tav: There is a default value of .6em.
  Tav: Might be useful for there to be a suggested value for
       mathematical values.
  Tav: Firefox uses ? for the baseline which is not correct.
  heycam: Easiest thing to get at.. nobody uses one.
  heycam: Had some discussions in Houdini over the weekend -
          exposing baseline to script -
  heycam: We didn't want to expose guesses - is my recollection
          correct?
  astearns: We want to expose what is available for the font and the
            baseline but browsers need some heuristics.
  astearns: It'd be nice to have standard heuristics so things don't
            jump around between browsers.

  SteveZ: A little bit more subtle than that.
  SteveZ: Came up with V1 for Houdini api-
  SteveZ: restricted to ideographic or alphabetic.
  SteveZ: Fairly reliably expect - come up with reliable heuristics -
          expose in future version of Houdini
  SteveZ: Don't start with a hard problem to solve.
  SteveZ: Haven't specced a good way to give that heuristic yet.

  Tav: It could be possible to measure these values from a font.
  Tav: Some fonts might be difficult because they only have ?.
  Tav: The mathematical fonts would use the minus character.
  AmeliaBR: Not sure the original SVG spec had a sentence that if
            the exact value wasn't available UA should synthesize
            appropriate heuristic.
  AmeliaBR: One option is to keep vague opening - vendors? choose to
            apply a fraction of em/ex
  AmeliaBR: or translate the glyph that way...
  AmeliaBR: Other option is to give explicit easy to calculate
            heuristic.
  AmeliaBR: How do you expose data to script and houdini?

  SteveZ: One of the action items for inline spec is to come up with
          standard heuristics.
  SteveZ: This is for interoperability, if things are different
          everywhere people will be unhappy.
  SteveZ: Need to gather data for determining these heuristics.

  Tav: Chicken and egg problem - no one uses it.
  Tav: The same issue is for Hebrew which is top aligned, most fonts
       don't have reliable values except for alphabetic and emba(?)
  astearns: Specially in the case of Indic - font worked well enough,
  astearns: everyone uses it.
  astearns: We could either have heuristics that every browser must
            interoperably implement
  astearns: or we could allow browsers to implement better heuristics.
  SteveZ: Why don't we wait for data before deciding?
  astearns: That sounds good.
  Tav: That concludes my issues.

  astearns: thank you.. lets see.
  astearns: CSS sizing?
  gregwhitworth: Covered yesterday.
  astearns: How about CSS alignment?
  gregwhitworth: fantasai?
  fantasai: I don't have anything for that.
  fantasai: Nothing to add.

Received on Thursday, 24 March 2016 00:01:51 UTC