- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 27 Jun 2013 18:24:51 -0700
- To: "www-style@w3.org" <www-style@w3.org>, www-svg <www-svg@w3.org>, "public-fx@w3.org" <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.* Reusing Stroke and Fill in CSS ------------------------------ The CSS and SVG WGs discussed the possibility of reusing the SVG 'stroke' and 'fill' properties to stroke and fill text in CSS. Some concerns raised: - controlling pattern fill boundaries when an inline breaks across lines - figuring out appropriate initial values and interaction with 'color' - inheriting a pattern fill doesn't work in CSS; need to know which element specified the pattern, otherwise adding unstyled inline around part of the text will reset the pattern - SVG properties don't follow the CSS shorthanding patterns; need to check back-compat wrt whether this can be fixed - need some control over where the stroke sits on the glyph outline ACTION fantasai + Tab: Write proposal for using stroke and fill for CSS text. SVG Text Wrapping ----------------- Discussed SVGWG's proposals for adding soft-wrapping to SVG: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Wrapping_Text http://tavmjong.free.fr/SVG/TEXT_FLOW/ The goal is to re-use CSS functionality (and layout engines) for SVG text layout. No objections so far to proposal to add width to <text> for wrapping; however it was felt by some that for formatting multi-block content, HTML markup should be reused. In general, people want CSS text formatting to Just Work in SVG, not require special rules for SVG text content. ====== Full minutes below ====== Reusing Stroke and Fill in CSS ------------------------------ heycam: topic added from CSS side heycam: did someone have a specific proposal Tab: it was me fantasai: we've had requests to be able to do fill and stroke on letterforms fantasai: webkit has text-stroke property. Might make more sense to reuse existing SVG properties. * plh wonders how confusing color and fill are going to be for devs fantasai: Complication is filling with pattern or image of some kind... how to handle line breaks is complicated fantasai: stroking or filling with color is straightforward <jdaggett> the webvtt guys have 'text-outline' as part of their spec <jdaggett> fill/stroke would be a better way of supporting that heycam: why do line breaks complicate things? fantasai: need to find the bounding box fantasai: might slice or take bounding box or fill separately per fragment dbaron: we do sort-of have a property for this already http://dev.w3.org/csswg/css-backgrounds/#box-decoration-break dbaron: we do sort of have a property for this already: http://dev.w3.org/csswg/css-backgrounds/#box-decoration-break fantasai: do we reuse that property or have separate control? heycam: what does box-decoration-break do? fantasai: determines how it's handled for borders and background fantasai: That's background, this is about foreground. heycam: That's one issue. Another is defining how color property and fill/stroke properties work together and whether their initial values allow same behavior for existing things. dirk: I think the first question is do we want something like that. dirk: Before we talk about page break or line break or whatever. fantasai: simplest are fill-opacity and stroke; fill could deal with later dirk: I think fill at least as important as stroke dino: webkit currently has custom property for gradients in text -- -webkit-background-clip -- horrible thing with backgrounds, for filling text. Can't then do background. dino: want to be able to say fill text with gradient/color/pattern; seems pretty standard for CSS fantasai: additional complication is that color inherits fantasai: so each element paints with its own color property fantasai: if you add more elements nothing changes unless you set properties on those elements fantasai: you want pattern to be consistent across an entire paragraph with elements inside... heycam: in SVG, two options (1) define pattern area in coordinate space of elements or (2) define relative to bounding box of element that's using that paint heycam: but for tspans within a text element we use the bounding box of the text element as a whole dbaron: don't think (1) works with CSS model heycam: agree heycam: so what happens with linear-gradient on a paragraph with multiple spans... dbaron: background doesn't inherit [not minuting entire discussion here] dino: fill/stroke/color inherit and background doesn't; don't want a new style of fill for every child fantasai: that would be a problem heycam: why would fill and color have different inheritance? fantasai: if you're setting a pattern need to know which element initiated the pattern heycam: seems odd for fill and color to have difference in whether they inherit, similar actions heycam: I think we should first see if people think it's a good idea for fill and stroke to work for text... then work out issues if people like it. dirk: always have option to have different properties dbaron: I think it is a good idea to use fill/stroke. Would like to see that work. dbaron: We could do it by turning fill/stroke into shorthand that sets both an inherited and non-inherited property heycam: ??? dbaron: Say 'fill' is a shorthand for 'fill-pattern' and 'fill-root' heycam: so having text-stroke and text-fill not inherited and shape-stroke and shape-fill (for SVG) inherited dbaron: latter of which has 'normal' and 'establish' or something dino: You only want this fill/stroke to apply to text dino: that's one reason in webkit it's text-stroke dino: do you ever want to stroke a box? fantasai: that's what borders are for ?: just on text dino: then why not just do text-fill and text-stroke dirk: if you say ... should be a shorthand ... inheritance problem ... dino: sounds fine to me fantasai: in SVG stroke just sets color of something ... weird heycam: might be beneficial for 'stroke' to be shorthand to stroke-paint and stroke-width and ... fantasai: yes, that would follow pattern of CSS a lot better dirk: what does stroke-paint stroke-width mean? heycam: stroke-paint would be what stroke is currently fantasai: then you can set all the stroke-related properties with stroke fantasai: if you just want to touch the color you say stroke-paint heycam: might be more convenient for SVG anyway fantasai: possible without breaking the Web? heycam: yeah, probably fantasai: depends how often people use it in CSS syntax rather than in SVG file fantasai: because stroke-width: ...; stroke: ...; would reset the first <shepazu> (what would stroke: blue; do?) heycam: so I feel like somebody should look at these issues and come up with proposal for integrating dirk: problem here is we have the attributes dirk: [too fast] heycam: we already decided to allow font shorthand as presentation attribute heycam: you take all the presentation attributes in a particular order dirk: cannot modify this order in the dom <SimonSapin> shepazu, if it’s a shorthand, set stroke-paint to blue and stroke-width to the initial value <shepazu> SimonSapin, then it won't break the web heycam: might not have made this change fantasai: for sure the stroke attribute would map to stroke-paint... it would have to fantasai: never mind heycam: anybody think it's a bad idea to try to allow paints in stroking text? Bert: principle is good, worried about syntax fantasai: in SVG, if you stroke a letterform, where does the stroke lie with respect to the glyph outline? dirk: it half overlaps the fill <jdaggett> seems like we need someone to work on a draft proposal tav: can change the order now <jdaggett> i think you want to have inset/outset control <jdaggett> look to postscript for a good model * fantasai agrees with jdaggett heycam: does webkit-text-stroke paint on top of fill or beneath? dirk: same as SVG tav: most of the time you want fill on top of stroke fantasai: if you put fill on top of stroke, looks fine when fill is opaque, otherwise looks dumb fantasai: would also lead to author confusion about stroke width fantasai: so I agree with jdaggett, should have control over where stroke is centered dirk: ??? <jdaggett> also, japan has *lots* of examples of double stroking of text heycam: we have proposal for that tav: should we put that in? dirk: we did <jdaggett> white stroke surrounded by black stroke <shepazu> +1 to controlling stroke centering Bert: if you're doing filling of text you might want text-shadow to have inset keyword fantasai: inset in plans for text level 4 dirk: stroke and fill don't need to overlap... have a new property so they don't need to heycam: called stroke-position? heycam: which we have a proposal for, to go in SVG2 <Cyril> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_position fantasai: I think Tab and I can take an action to draw this one up. ACTION fantasai with Tab, draw up proposal for using stroke and fill for CSS text <trackbot> Created ACTION-562 [shepazu suggests pulling him and jdaggett into that discussion for help] jdaggett: For text stroke and text fill, parameterization could be a complication... would like to work through multiple proposals. SVG Text Wrapping ----------------- heycam: so recently in SVG WG meeting yesterday or the day before we discussed how to satisfy requests for wrapping text in SVG, long wanted heycam: people may remember the proposal in SVG Tiny 1.2, for <textArea>, with text layout different from CSS... objections because different from CSS heycam: 2 things we want: (1) to do simple rectangular text and (2) text in shapes, which SVG also had a proposal for long ago heycam: so we want to follow CSS For text in shapes heycam: and we've been discussing simple discussion for our current text to wrap text to a particular width <shepazu> simple: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Wrapping_Text and more powerful: http://tavmjong.free.fr/SVG/TEXT_FLOW/ heycam: tav will talk about what we need from arbitrary shapes perspective and doug will talk about simple rectangular wrapping tav: This describes what's in SVG 1.2 flowed text. Partially implemented by Batik and Inkscape tav: that didn't take -- was complicated and not consistent with CSS tav: looked at what we can do to keep consistent with CSS. tav: propose to use shape-inside, shape-outside, wrap-margin, wrap-padding tav: here's an example, with a shape in an SVG circle (showing examples from http://tavmjong.free.fr/SVG/TEXT_FLOW/ ) tav: mocked up flowing between shapes (from 1.2 proposal), though told this conflicts with regions from CSS tav: and here's one with some exclusions tav: a couple issues, 1 is CSS region seems overkill for our needs tav: and not close to being finished stearns: what you want that's different is a comma-separated list of regions? dirk: so shape-inside and flow to the next shape at the same time tav: shows example with text flowing from circle to square stearns: in regions you'd have a list of selectors selecting ... dirk: he means shapes... he wants shape-inside to have comma-separated lists Bert: so why does the text go down one and then down the other? tav: how to do without using CSS regions... if you don't have CSS support? SVG doesn't rely on having CSS. Jet: and the rest of the words are just clipped? fantasai: so what happens if someone increases the text size? tav: just falls off the end rossen: ... overflow: hidden... on both ...? tav: next problem we have is SVG doesn't have <br> and <p>, though could probably rely on 'white-space', though maybe not ideal tav: question is what's the best way to do line breaks and paragraphs tav: one thing we could do is position text in tspans by having x and y. We'd keep them, but in flowing text you ignore them. But if it doesn't it can serve as fallback for old renderers. tav: though if renderer doesn't have right font, might be positioning problems, but would be readable tav: one thing SVG doesn't have is a wrapping context... doug has a proposal <shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Wrapping_Text doug: link to my proposal doug: there's a width and (optionally) height property on svg:text element doug: and it basically passes in the position established via x and y doug: and the width, and optionally the height doug: as the inner box (rendering area), and has CSS engine do text wrapping doug: cameron has rough prototype heycam: in local build doug: Cameron was able to implement in a couple of days. doug: The idea is to treat SVG text like you would a paragraph or text in a div. If it has a width, it wraps to that width. If has a height, clips to that point. doug: options are allowing scrolling with overflow:scroll, allowing padding/margins. I don't have a strong feeling about padding/margins either way. I think important part is wrapping. doug: But the basic idea is to use the width property on the existing text element to wrap the text. doug: Advantage to that is that the natural fallback is that the text still appears but is not wrapped; better than not appearing at all. heycam: In SVG, when I get to rewriting text chapter, I plan to define non-wrapping text this way: heycam: SVG currently has x and y attributes to specify positions for character (not glyph!) positions heycam: we're treating that as a ... for defining CSS layout of the text heycam: you set up a block that has indefinite width and treat the text element itself as the block and tspans within that as inlines, perform CSS text layout, and then if any glyph positioning, do that as a layer on top of the CSS layout. heycam: so to handle restricting the text to a width would just mean setting that initial block width to that width rather than being exceptionally wide heycam: so purpose of talking about these 2 topics here was to see if you think we're heading of the rails in any particular way, or have any opinions on how better to integrate with CSS stuff heycam: so we don't work away for months and then have people say it shouldn't be done this way fantasai: I think this makes sense fantasai: I have concern about x and y positions and how that works with line breaking * Rossen wonders how different this is from foreign object in svg? fantasai: line breaking determined by layout engine and could vary between engines, e.g., fonts, hyphenation engine fantasai: those glyph thingies probably assume a certain type of wrapping heycam: in the past without support for auto-wrapped text, people used x and y to manually wrap heycam: so as tav was describing for text in shapes, where x and y could be fallback positions, we'd do the same thing here for rectangular text, so in this mode x and y would be ignored when wrapping is supported heycam: doug, did you have different view? doug: I think various options we could explore. doug: Key thing is I want CSS WG to understand we're proposing to treat text in SVG much like text in HTML, and use existing CSS text layout engine that browsers already have to do text wrapping. doug: I think this is simply solved by using what CSS already has, in SVG. doug: There may have to be tweaks or bits here and there, say text-alignment, alignment-baseline, for certain effects or other things... we'd have to specify that, but would run by CSS WG. glazou: Also in Mozilla's XUL have to include HTML inside of XUL. glazou: not specific to SVG and text rossen: how is this different than foreignObject? heycam: Was just about to say that I think there's a real desire to not have to resort to having to use foreignObject -- ugly feature syntactically -- for simple cases like rectangular text layout. But foreignObject would still always be there. heycam: But for simple cases would be nice not to have to escape into HTML world. dino: Shouldn't say these are simple cases. If you're going to do a CSS block, it should be a CSS island inside SVG with all the CSS properties. dino: weird, x,y is bottom corner in SVG top corner in CSS heycam: In my approach, I switched on whether width was specified, and made x,y be top/left when width was specified heycam: definitely would want to specify it like that, now you're in CSS mode, read over here tav: in that case fallback doesn't work dino: I'm not so worried about fallback dirk: margin/padding has.. (cutoff) doug: popular libraries like d3.js where people are doing labels doug: script library that makes SVG diagrams very easy doug: I talked to several people using d3, people want wrapping text without having to use HTML doug: for those cases having fallback to older browsers would be really nice, fall back to one line doug: this is why I mentioned alignment-baseline doug: could say whether origin affects glyph cell or character cell, top/left or baseline doug: dino, I'm fine with saying "this is a CSS block and behaves like one" doug: whatever's easiest for implementors and authors... authors would expect padding/margin dino: then hyphenation, kerning, etc. heycam: for non-wrapping case we'll just make all CSS properties work on single-line text too heycam: at least in Firefox (soon) we'll just do CSS layout underneath for text, so easy to let properties just work dino: so you're suggesting effectively flatten text content of element dino: basically flatten tspan positioning dino: if I say text width is 100 and inside tspans with x and y... tspans get thrown out heycam: tspans are effectively spans even in the single line case doug: part of my idea was actually that in case where you wanted to have a line break, break element, might use tspan with dx and dy doug: to allow simple breaking in SVG so you didn't have to pull in HTML to do paragraph doug: obviously lists etc. out of scope doug: for simple text breaking thought could use tspans for that dino: should be a single block dino: if you want >1 block, use HTML dirk: why not have new element in SVG for anything from HTML world? heycam: like foreignObject? dirk: with no <html><body> etc. dirk: inside this tag you have HTML world dbaron: You don't need <html><body> etc. inside <foreignObject>. Do need namespace. dbaron: how much more violent agreement do we need here? heycam: Just wanted to make CSS WG aware of what we're doing so we can get course corrections; mail to list fine too. r12a: when you collapse the tspans, how do you separate the last word in the first tspan and the first in the next? heycam: don't really collapse dino: meant just ignore x and y attributes and use them as spans doug: I think these details can be sorted out in spec... don't need to go into them in this meeting. doug: What I'd like in this meeting is ... doug: was some concern in SVG F2F that CSS WG might have some objections doug: so we wanted to socialize it with CSS WG doug: so we wanted to make sure thought a good path forward doug: don't know if we need a resolution per se doug: nice to know if this is a reasonable direction glazou: I think you have that consensus. Bert: I'm not going to say what SVG should do... but why not just stick with foreignObject? Tab: You need to give it a height, you can't just flow an amount of text in. doug: Bert, the answer I've gotten from people doing it every day, people want 1 element rather than 6. Bert: soon you'll need hyperlinks, hyphenation various: already have those doug: if you need anything more complicated, you can use foreignObject Bert: fine by me, just seems like double-work for half solution Bert: but no objection <br type="lunch" data-endtime="13:00">
Received on Friday, 28 June 2013 01:25:29 UTC