W3C home > Mailing lists > Public > www-svg@w3.org > June 2013

[CSSWG][SVGWG] Minutes Tokyo F2F 2013-06-05 Wed AM II: Stroke/Fill on Text, SVG Text Wrapping

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 27 Jun 2013 18:24:51 -0700
Message-ID: <51CCE5E3.1070507@inkedblade.net>
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:
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
   dbaron: we do sort of have a property for this already:
   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
   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
   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:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:44 UTC