- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Mar 2016 20:00:52 -0400
- To: www-style@w3.org
- Cc: public-fx@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.
=========================================
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:50 UTC