- 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:51 UTC