[CSSWG] Minutes Sydney F2F 2016-02-03 Part II: Fill & Stroke on CSS Text [css-text]

  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:
      Major points include
      * Redefining 'fill' and 'stroke' as shorthands of other
      * Incorporating background-like image capabilities
      * Handling inheritance / nesting via fill-origin and
      * 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
      * Multiple strokes were requested
  - It was noted that stroke-align may be too difficult for this
  - 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.)


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
  fantasai: You could also ... solid filled and transparent stroke.

  <BradK> Or always have the text knock out the stroke


  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-*

  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
  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
  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
  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
  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
  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]


  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
  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

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.


  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.


  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
  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
  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
  AmeliaBR: Can do with default style sheets ... it's just an extra
  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

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
  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
  BradK: For decorate borders
  BradK: my experience
  BradK: make each one wider than the one above it, and then knock
         out the text shapes.


  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
  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

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