- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Mar 2016 20:00:36 -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.
=========================================
Fill & Stroke on CSS Text
-------------------------
- fantasai presented the work she and TabAtkins had done to draft
how fill and stroke properties effect CSS Text. The work is
currently in the text-decoration L4 spec:
https://drafts.csswg.org/css-text-decor-4/
Major points include
* Redefining 'fill' and 'stroke' as shorthands of other
properties
* Incorporating background-like image capabilities
* Handling inheritance / nesting via fill-origin and
stroke-origin
* Need to investigate more deeply into which "boxes" serve as
sizing/positioning origins for text
* SVG has text-decoration fills, which need to be handled as
well
* Multiple strokes were requested
- It was noted that stroke-align may be too difficult for this
level
- Wrt dashing
* The dashing origin for text is not defined; therefore might
not be appropriate for text to have dashed strokes.
* Dashing on strokes may need to be syncronized with additional
dashing capabilities for CSS borders
- RESOLVED: Merge heycam's spec paint spec with this proposal and
put into FX repository
- RESOLVED: Add -webkit-background-clip-text to the spec stating
that authors must not use it but browsers may support
it. (Deprecated appendix.)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2016
Scribe: tantek
Fill & Stroke on CSS Text
=========================
astearns: fill & stroke on CSS text - who put this? fantasai.
[fantasai projects]
<fantasai> https://drafts.csswg.org/css-text-decor-4/
fantasai: TabAtkins and I had action item from couple of years ago
fantasai: to draft up fill & stroke properties from SVG
fantasai: and how they apply to text.
fantasai: We did that a few weeks ago.
Spec Home
---------
fantasai: Which spec should they go in?
fantasai: We stuck them in text-decoration.
fantasai: They might need to go into their own separate spec.
fantasai: So that's one open question.
fantasai: Where should we put these properties?
heycam: I broke-out some improvements to the stroking properties
which we decided to defer from SVG2
<heycam> https://svgwg.org/specs/strokes/
heycam: They have not been made a working draft yet,
heycam: should be a single place for all of these
heycam: rather than multiple documents.
heycam: I don't particularly mind where they go.
heycam: So this is just breaking out the SVG definition and then a
couple of extensions to those values.
fantasai: I think we can merge the two
Stroke Alignment
----------------
fantasai: for stroke-alignment we shortened to stroke-align.
fantasai: We considered stroke-position (analogous to
text-line-position) but that would be confusing with all
the image stuff that has to go in.
heycam: So that's the alignment property that...
fantasai: We were talking about it last time.
fantasai: We had agreed to add it.
fantasai: It doesn't work to stroke text with center alignment
very well if you have a semi-transparent stroke.
tav: I looked into implementing stroke-alignment.
tav: and it was quite complicated.
tav: What you do with the end caps.
tav: It gets quite complicated.
fantasai: I think the round cap would be a full / whole circle
fantasai: the rest of it would look like you clipped out the
shape itself.
tav: What do you do about paths that cross each other?
tav: How do you handle the fill rules?
tav: I would love to have,
tav: thought it would be easy,
tav: turns out to be very complicated.
heycam: Presumably these issues don't crop up with text.
fantasai: We can put it into the draft.
Tav: Would be good to work on it.
<AmeliaBR> Examples of these problems in the Issues in SVG
Strokes: https://svgwg.org/specs/strokes/#SpecifyingStrokeAlignment
Tav: One thing that was missing, SVG now has paint-order.
fantasai: We didn't think that would be needed in CSS.
fantasai: You never want to put the stroke behind the paint.
heycam: Conceptually yes, but in practice, outsetting the stroke
heycam: and making sure you don't get seams between the outer
stroke and the shape.
heycam: At least if you have opaque colors.
Tav: You could also do the painting and then apply the opacity to
that.
fantasai: You could also ... solid filled and transparent stroke.
<BradK> Or always have the text knock out the stroke
Shorthanding
------------
fantasai: We re-arranged the way the properties interact so we
have shorthanding.
fantasai: So stroke is stroke-...
fantasai: same with fill.
fantasai: We put in all the background properties.
fantasai: Have all been put in as equivalent fill-* and stroke-*
props.
fantasai: wrt fragmentation
fantasai: Do you glue everything back together?
fantasai: Do you take bounding box?
fantasai: Do you clone it separately?
fantasai: Added fill-break and stroke-break to decide
heycam: Shorthand for stroke, I'm concerned that SVG defines
specifying stroke-width before stroke.
heycam: I don't know if you done any research.
fantasai: We had two options for stroke shorthand.
fantasai: 1. include all stroke properties
fantasai: 2. include only paint related properties, geometry
separate
fantasai: Could go with either option
Image Fills/Strokes
-------------------
AmeliaBR: Couple things I wanted to break out.
AmeliaBR: So far SVG has talked about breaking out stroke and fill
point into many different sub-properties
AmeliaBR: to match the CSS background,
AmeliaBR: That seems to be what they have done here,
AmeliaBR: would love to get that into SVG2.
AmeliaBR: That puts a lot of timing on getting all the issues
cleaned up.
AmeliaBR: When I looked at it previously the main issues come
around how do you work the CSS background properties
with SVG paint servers, things like object bounding boxes.
fantasai: We handled this with the fill- and stroke-origin
properties.
fantasai: On the background where it is transparent, the text is
painted by itself.
fantasai: You need to know what element is setting the stroke.
fantasai: If I am an element and parent has a fill, need to not
just use same image but also same origin.
fantasai: We decided to make the image properties inherit
fantasai: And use a 'match-parent' value on the -origin properties
fantasai: to mean "use the same fill positioning area as my parent"
fantasai: so that if you set a bunch of image fills on the
paragraph, those properties will inherit to the links
and anything inside it.
fantasai: But you would use the positioning area defined by the
paragraph
fantasai: so that it looks like all part of the same image fill.
fantasai: Everything has got the same positioning pattern.
fantasai: You can even do some of the text with a different color
pattern, while keeping the fill pattern aligned across
the entire element.
fantasai: When you set the stroke or the fill, you choose which
box to use as origin: content-box, stroke-box, fill-box
fantasai: But in the shorthand, instead of setting fill-origin to
initial value 'match-parent'
fantasai: When you use the shorthand you set your fill, it will
automatically make that element the origin for that
element's fill and for its descendants.
AmeliaBR: That makes sense,
AmeliaBR: does enable matching up with existing SVG behavior
AmeliaBR: which is that TSPANS and other child elements match the
bounding box of the parent text element for painting and
scaling the paint content.
AmeliaBR: There are a couple of other confusions with paint
servers, because the paint server itself has these two
different options
AmeliaBR: for objectBoundingBox vs. userSpaceOnUse.
AmeliaBR: Those are issues we have seen come up with filters and
masks and clip paths.
AmeliaBR: We don't know how those translate for non-SVG content.
Synchronizing with SVG
----------------------
AmeliaBR: Overall this is a great draft.
AmeliaBR: I'd like to see all these options and controls in SVG2
AmeliaBR: or whatever part of SVG start supporting multiple
layered fill & stroke.
AmeliaBR: Right now all we have in the spec is single complicated
shorthand property.
AmeliaBR: At the very least we have to make sure that the syntax
we are using for the fill and shorthand properties
AmeliaBR: are consistent with all the options you are adding.
AmeliaBR: There is a timing issue about what spec should have all
these in it.
fantasai: If we are applying these to CSS, these should not be in
the SVG spec
fantasai: we need these either in a CSS module or an FXTF module.
Origins for Glyphs
------------------
fantasai: There's a couple of issues
fantasai: 1 was SVG paint server issue that was mentioned
fantasai: 2 there was the question of default fill origin. if you
don't set, should it default to the content box or the
fill box?
fantasai: So content-box, padding-box, border-box are defined as
CSS for SVG shapes. We tried to be consistent with
Masking.
fantasai: box ... box ... box...
fantasai: If it's an inline element, the intention was the glyphs
themselves, not the box.
fantasai: If you have Zapfino and want to fill it so that it goes
from super dark at the top to super light at the bottom
fantasai: it needs to include all of the glyph bounds, including
any ascenders and descenders outside the em box.
heycam: For text the fill bounding box is the one that gives you
the union of the glyph cells.
heycam: A different name like ink-box may make sense.
fantasai: What about the stroke-box?
heycam: Yes stroking box.
fantasai: What does the stroke box mean for SVG? is the fill box
sometimes smaller?
fantasai: What do you do when you have those kinds of glyphs?
heycam: Maybe it's an internal naming term in the spec that
conflicts.
heycam: Mention fill-box in the SVG spec
heycam: and then change the glyph cells to something else?
<AmeliaBR> That's probably an issue in the SVG spec currently
(multiple bounding boxes not well defined for text)
[fantasai goes to draw a picture]
Layering
--------
AmeliaBR: One thing, have you looked at it yet, I've seen it come
up in SVG:
AmeliaBR: Painting order for fill and stroke, it's a question of
when glyphs overlap, or stroke from one overlaps
another, or text-shadows, whether you draw one glyph at
a time (most SVG implementations), or one element at a
time.
AmeliaBR: Not sure if that is spec'd.
AmeliaBR: It's something that results in unpleasantly ugly options.
AmeliaBR: I want it as an option in the spec eventually.
fantasai: In CSS the text for shadows, the shadows are supposed to
be just below the text.
fantasai: The shadows are required to all be underneath all the
text for a given element.
fantasai: But we also encourage the user agents to paint the
shadows behind all of the text in a run together insofar
as possible.
heycam: ... strokes underneath the other glyphs...
fantasai: ... because if you have negative letter-spacing you have
glyphs that end up on top of each other
ACTION fantasai: investigate the paint order of the glyphs with
respect to shadow and stroke and fill
<trackbot> Created ACTION-755
AmeliaBR: It's also ugly when you have glyphs showing boundaries
between glyphs when they're supposed to look continuous,
e.g. in cursive fonts/scripts
fantasai: Excellent point and why we should bias towards not doing
that.
Paint Servers
-------------
heycam: Before you were talking about issues with SVG paint servers
heycam: is that with the URL syntax?
heycam: Wame issue as in masking spec?
fantasai: We didn't really go too much into the paint servers and
how they should work.
fantasai: We wrote it up as if paint servers didn't exist (laughter)
fantasai: haven't really incorporated that aspect into the spec.
heycam: In general this looks good.
Naming
------
fantasai: One other thing we came up with:
fantasai: bikeshedding issue.
fantasai: Getting pissed off at how inconsistent SVG names things
fantasai: I made a table of this is the syntax, this is the syntax
we wished we had.
heycam: To change it?
fantasai: We don't know
fantasai: we just want to ask SVG WG what they think
<AmeliaBR> is there a link?
<astearns> https://drafts.csswg.org/css-text-decor-4/#perfect-world
heycam: Many things are possible if you're willing to put up with
aliases to your code paths.
heycam: We can try
heycam: we tend not to introduce aliases to fix things like this.
Dashing
-------
fantasai: The dash-adjust property?
heycam: Nobody implements that yet.
fantasai: We made some slight modifications to the syntax.
heycam: tav just asked is that really useful for text?
heycam: I have a concern about dashing on text in general.
heycam: It exposes things like where is the implementation
considering the start of the glyph,
heycam: I almost want to disallow dashing on text completely.
<AmeliaBR> We (SVG WG) has already decided that text does not have
a canonical origin for dash-offset
fantasai: I don't have a strong opinion on that.
fantasai: We were talking about it because of borders and wanting
to be consistent.
<BradK> +1 for borders
<BradK> +1 for adding dashes between words
Text Decoration
---------------
fantasai: Anyone that wants to dig more into anything...
fantasai: the shorthanding issue is something we need a good
understanding.
fantasai: should stroke be just painting.
fantasai: there's one that deals with geometry.
fantasai: ... paint stuff.
Tav: SVG also has text-decoration where you can put different
stroke and fill.
fantasai: How?
Tav: part of SVG 1.1
fantasai: I haven't read it.
AmeliaBR: In SVG2 there are two new properties that are replacing
text-decoration-color
AmeliaBR: with text-decoration-fill and text-decoration-stroke
AmeliaBR: and so they would naturally fit with these schema.
<AmeliaBR> https://svgwg.org/svg2-draft/text.html#TextDecorationFillStroke
fantasai: I don't think you can replace text-decoration-color
because we already have that in CSS. We have to define
the relationship.
Tav: I think that's what we do.
AmeliaBR: ... you have fill-color having an initial value of
current-color
AmeliaBR: Can do with default style sheets ... it's just an extra
complication.
fantasai: I'm a little confused.
fantasai: You want the fill-color not to default to currentColor?
AmeliaBR: In SVG you have to set fill to currentColor.
AmeliaBR: If you want the color property to have an effect.
fantasai: So the default is...
AmeliaBR: Fill defaults to transparent black.
fantasai: That could be handled by a user agent style sheet.
Next Steps
----------
heycam: Next steps?
fantasai: You have to tell us if you want this in a separate
"paint" spec
fantasai: and we need to incorporate your spec.
heycam: I'll take a look at the two specs.
AmeliaBR: I would vote for having a "paint" spec that could be
used by both SVG and CSS
AmeliaBR: that section in SVG2 is not very defined now, but is
something people want for the multiple layered fill &
stroke stuff.
AmeliaBR: Would be good to get that cleaned up
AmeliaBR: even if implementations for SVG text were slower to
happen.
Multiple Strokes
----------------
Tav: Does this allow for having multiple strokes? with different
stroke widths?
fantasai: We didn't add that to the spec.
Tav: Sometimes you build up complicated paths like a road, center
of the road red, dashed lines on shoulders.
fantasai: That's going to be tricky because we're already using
commas in the stroke-image
fantasai: so we can't use comma-separate syntax
fantasai: unless you're ok with using image fills for everything.
Tav: How would an image fill work per path?
AmeliaBR: I don't think it would be a complication
AmeliaBR: it is matter of the stroke geometry properties also
being list properties.
fantasai: Then you would be able to define geometry, but how do
you define what color they are?
heycam: If you really had to you could have CSS image values you
would "salt"(?) with colors.
fantasai: Those layer. You want to have things side by side.
Different kind of list.
fantasai: So you have a two color stroke, one red, one blue.
fantasai: If you have two colors, you will get red and blue
stacked on top of each other in z-order.
fantasai: We don't have a syntax for having multiple fills
fantasai: because the fills are already a list of z-ordered images
fantasai: and you're asking for laterally stacked fills.
AmeliaBR: The idea is that each stroke would be a different stroke
layer
AmeliaBR: the only place it would get confusing, is
AmeliaBR: that the CSS background syntax has multiple images but
only one color at the bottom.
AmeliaBR: It would be nice to be able to have multiple colors
especially for stroke
AmeliaBR: one way would be to use the image function to have a
solid color.
fantasai: I think I understand what you're saying now
fantasai: Thought it was similar with people asking for multiple
borders; they want those strokes side-by-side, not
stacked.
BradK: For decorate borders
BradK: my experience
BradK: make each one wider than the one above it, and then knock
out the text shapes.
-webkit-text-fill
-----------------
Jet: Question about fill:
Jet: It's great that these specs are coming around.
Jet: We (Mozilla) are currently being lobbied to implement the
circa 2006 -webkit-text-fill-color
Jet: My question is about the delta between the fill color stuff
we are working on here
Jet: and the implementation details of -webkit-text-fill-color
Jet: and if there is a delta
Jet: then for the same reasons we have to implement the -webkit-...
Jet: then webkit and blink can't change either.
Jet: Is that something we can align on
Jet: to cover existing content?
fantasai: Those should ideally map to what we are doing here.
fantasai: It should just work that you drop the -webkit-text-
prefix and just get the stroke-color
BogdanBrinza: If you implement ...
BogdanBrinza: What we've seen on some websites is fill but not
stroke, it makes things worse.
fantasai: We decided to reuse the SVG properties because they do
the same things already.
AmeliaBR: They match up pretty well.
AmeliaBR: They should match up pretty well.
AmeliaBR: The other one that should match up is background-clip
AmeliaBR: because that's where I most often see text-fill to
transparent in order to just show the background fill to
text.
astearns: And that's the next topic.
hober: Question:
hober: The stroke-align property
hober: could we add an issue?
hober: CG doesn't really provide this capacity
hober: so I'd rather not have it.
hober: Maybe too early to mark at-risk?
fantasai: We can mark it at risk.
<astearns> (or add a note that we're not sure it's implementable)
hober: Basically we can do center.
fantasai: Which is the initial value.
fantasai: goal of this spec is to replace the SVG properties ...
fantasai: not sure of the web compat impact
astearns: let's close this topic
background-clip-text
--------------------
Scribe: alancutter & nainar
<jet> https://webkit.org/blog/164/background-clip-text/
jet: Another request from core web compat team circa 2006/2012
jet: background-clip-text.
jet: Desire to specify a way forward in a universal way "correct
way"
jet: implement -webkit- syntax in FF
jet: See if we can write spec text around that behavior.
jet: First thing - see documentation that can be normative text
jet: around the existing behavior.
jet: Did edge team implement this -webkit- one?
<hober> https://webkit.org/blog/164/background-clip-text/
gregwhitworth: I don't think so - filed multiple times
gregwhitworth: Do want to implement haven't gotten around to it.
<BogdanBrinza> Edge didn't implement background-text-clip but it's
known issue on our backlog.
jet: Interest in specifying it.
jet: Webkit behavior appear as normative behavior.
jet: Is it desirable for it to appear as normative text or should
it be a compat spec entry?
fantasai: Should be a compat spec entry.
fantasai: Should be a background level 4 module entry.
fantasai: If it needs to exist for engines to implement for web
compat,
fantasai: spec the prefixed thing - unprefixed thing.
jet: I'll take an action to write
jet: the actual defacto spec for the webkit property and run it by
people who don't have implementation.
fantasai: Do we resolve to add to background level 4?
plinss: I really reaalllly dislike the idea of having a prefixed
and canonical spec.
plinss: We have quirks spec for stuff that isn't CSS do for web
compat.
fantasai: It's harder to write spec - standards mode thing.
AmeliaBR: If the longterm goal is to use the new fill properties
does it make sense to have it in the same spec as the
fill properties.
fantasai: No because the value is for the background-clip property.
fantasai: Could put in here not, not as a fill/stroke value
fantasai: thats fine.
astearns: I like having it in the same spec as what is actually
CSS so people find it.
astearns: Are you okay with putting it in an appendix?
Florian: It is normative - authors must not use this - browsers
may/should support this.
fantasai: I think "may" is fine
Florian: Normative - must not use for users, in same spec - yes
ugly name - others names due to legacy that aren't branded.
plinss: I'm okay with it being in the ? spec as long as it's
clearly defined.
fantasai: You're a bad person if you use this.
plinss: Your website is bad and you should feel bad if you use this.
astearns: Proposed resolution is to add this to the spec with
caveats proposed.
astearns: Objections?
<tantek> W3C specs (e.g. HTML) have put things directly into
deprecation that were never in any previous W3C spec
<tantek> deprecation does mean that implementation should (or must)
support it but authors should not use it
RESOLVED: Add -webkit-background-clip-text to the spec stating
that authors must not use it but browsers may support it.
RESOLVED: Merge heycam's spec text with paint fx repository
<fantasai> Note to fantasai: switch default value to fill-box, map
it to padding-box, define more clearly that it's glyph
ink bounds on inlines. Or something
Received on Thursday, 24 March 2016 00:01:34 UTC