- 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