[CSSWG] Minutes Seattle F2F Wed 2014-01-29 PM II: Masking, Gradients, SVG Text Fills

Masking
-------

   Discussed mapping of CSS boxes (border/padding/margin/content) to
   SVG concepts.
   RESOLVED: Use the keywords fill/stroke/viewbox for clip-path/mask-origin/mask-clip.

   RESOLVED: Use roc's definition of obb/usou in HTML content - same geometry,
             coord space is 1 user-space unit wide/tall in obb, user-space
             unit = CSS px in usou.

   RESOLVED: New WD for Masking.

Gradients
---------

   Discussion of color functions used for gradient interpolation.
   RESOLVED: change CSS Images 4's specification of colorless color stops
             to use Rik's proposal (i.e. use power curves)

SVG Text Filling
----------------

   Discussed using multiple fills/strokes in SVG.
   RESOLVED: Import the background shorthand syntax for multi-fill and
             multi-stroke into SVG minus the attachment part of the syntax

====== Full minutes below ======

Masking
-------

   krit: During the LC period I got a comment and an objection.
   krit: clip-mask/etc take a <shape-box> argument.
   krit: Which determines what box the coords are resolved against.
   krit: Currently we're using the box keywords from B&B, plus margin-box.
   krit: SVG objected.
   krit: They make sense for CSS/HTML, but how do they apply to SVG?
   krit: In SVG we have "bounding box", which is a tight bound around the
         shape.
   krit: This doesn't include strokes/etc, just geometry.
   krit: So we also have "stroke bounding box" which includes stroke/markers.
   krit: Earlier in the week, we also discussed "viewport" in SVG.
         People asked about using the SVG viewport as the reference shape.
   krit: Scaling coordinates by the viewport is actually rather common in SVG.
   krit: So SVG thought it would be confusing to have "content-box" mean
         "bounding box".
   krit: Similarly for stroke-bounding-box, and viewport of the SVG.
   krit: I personally don't want to add three more keywords.
   krit: I think content-box and bounding-box are close enough to be useful
         to just use content-box.
   krit: Similarly, I think border-box and stroke bounding box are probably
         close enough.

   smfr: What about the bounds of filtered pixels?
   krit: People suggested painted bounding box, but that's very expensive.
   TabAtkins: Also infinite in some cases, such as blurs.
   smfr: Does CSS define the bounds of box-shadow?
   dbaron: No. Also, probably impossible.

   heycam: I think I'd like to have all of the CSS-related names map to a
           single SVG-related one, like maybe "bounding-box", and also
           have SVG-specific keywords.
   heycam: I'd like to match the names up with getBBox extensions.
   heycam: Right now we have getBBox() and getStrokeBBox(), but we should
           probably have it take a dictionary of things to include.
   krit: Does that imply we need another keyword for markers?
   krit: Does the CSSWG support doing extra SVG-only keywords?
   TabAtkins: I'm fine with it.
   florian: Me too.
   heycam: Does the CSSWG think it's a good idea to do the mapping between
           CSS and SVG?
   TabAtkins: I think content=>geometry and border=>stroke kinda make sense,
              but there's no padding analog in SVG, nor marker analog in
              CSS, so it's a bad idea overall.

   TabAtkins: I suggest for the svg boxes: svg([marker || stroke]?),
              similar to the bbox methods.
   krit: I think it's [marker | stroke] - one implies the other.
   heycam: Maybe not.
   krit: Viewport.
   TabAtkins: Don't want it at top-level, because it's a different meaning
              than CSS's viewport.
   krit: So svg([[marker || stroke] | viewport])
   heycam: I think it's weird to name it svg().
   krit: Fallback to the initial value (border-box) if you specify svg()
         on an non-SVG element.  Fallback to svg() (object bounding box)
         for reverse.

   krit: So we also need this in mask-origin, mask-clip.
   krit: Example: clip-path: circle() svg(marker);
   krit: Circle starting in the center of the marker box, radius equal to
         closest side.
   heycam: Does the default-fixing (for putting svg() on an HTML element)
           happen at computed-value time?
   TabAtkins: I think so, yeah.
   smfr: Yeah, possible.
   dbaron: Yeah. Maybe annoying.
   krit: We may have the same problem in SVG later.
   krit: If we take in CSS Shapes, for example.

   ed: Would it be worth having the "fill" keyword there as well?
   TabAtkins: Hm, I think so.
   <ed> having svg(fill || stroke || markers) would also match up with the
        paint-order property syntax
   <ed> spec link for paint-order, for reference:
        https://svgwg.org/svg2-draft/painting.html#PaintOrder

   heycam: SVG text, the default getbbox() for text actually unions the
           glyph cells (rectangles).  Same here?
   krit: Yeah.

   Bert: I think it's weird to see a function without parameters inside,
         like "svg()".
   TabAtkins: You can say "svg(fill)" if you want.
   heycam: Or just leave it alone - you'll get that behavior by default.
   smfr: should we use up a function called svg() for something that returns
         a box? Why not svg-box()?
   smfr: I think it's a weird namespacing hack to use svg() here.
   krit: My pref is to just use the keywords directly, and only allow one.
         Define them to be hierarchical - fill is inside stroke is inside
         marker is inside viewport.
   TabAtkins: Still don't like "viewport" as raw keyword.
   krit: viewbox?
   heycam: I think it's maybe useful which ones to include.  Maybe we can defer.
   <ChrisL> we have (geometric) bbox and decorated-bbox which includes
            stroke width, markers etc
   heycam: I'd probably be okay with just keywords for now, and do union
           stuff later.
   heycam: Maybe use the words bounding-box, stroke-bounding-box,
           decorated-bounding-box, and...?
   krit: viewbox?
   heycam: Too wordy.  fill/stroke
   heycam: Leave off marker for now, since I want it to actually mean the
           markers, not marker+stroke+fill.
   TabAtkins: But you're okay with stroke meaning fill+stroke?
   heycam: It does automatically - stroke bounding box is a superset of
           fill bounding box.
   krit: Anyway, resolve on these and figure out details in the SVGWG meeting?
   RESOLVED: Use the keywords fill/stroke/viewbox for clip-path/mask-origin/mask-clip.

   ed: The viewbox keyword, is that the viewport or the viewbox?
   krit: They're the same geometric area.
   TabAtkins: Only difference is the coord system established in each.
              And the shape functions so far don't use user-space units,
              so you can't detect that.
   heycam: And if we did allow, viewbox is what you'd want.

   krit: Last issue we discussed on Monday.
   krit: about usou and obb.
   TabAtkins: Just do what roc said.
   krit: [explains the issue again for SVGWG people]
   RESOLVED: Use roc's definition of obb/usou in HTML content - same geometry,
             coord space is 1 user-space unit wide/tall in obb, user-space
             unit = CSS px in usou.
   krit: I'd like to publish a new WD.
   RESOLVED: New WD for Masking.

Gradient Midpoints
------------------
Scribe: birtles

   cabanier: I wanted to show why there is a need for an explicit midpoint
             for gradients.
   TabAtkins: this is already in CSS Images 4
   TabAtkins: if you just omit the color
   cabanier: but some people were confused by that... it doesn't really work

   cabanier: I created this little application
   <cabanier> sample application: http://codepen.io/adobe/full/fhnBJ
   cabanier: by clicking on the gradient line you can add color stuff
   cabanier: and by dragging it to the left, you can see this effect as
             you approach the edge
   cabanier: a line starts to appear
   cabanier: your eyes play tricks on you
   cabanier: if you copy this and enlarge in photoshop you'll see this
             line is actually not there
   cabanier: it's just your eyes
   cabanier: but to get rid of that you can add a midpoint
   cabanier: and drag it along
   <cabanier> example of the formula:
              http://codepen.io/adobe/pen/ced9e76d276a1d6613b529e8524e4cad
   cabanier: you fill it in with this formula
   cabanier: by doing it this way you avoid the line
   cabanier: you create a curve that avoids the appearance of sharp changes

   TabAtkins: is there a theoretical justification for this formula?
   ChrisL: yes, it's based on a power distribution
   ChrisL: it gives you curves but it doesn't give you continuity at where
           the curves join
   ChrisL: it's an improvement but it doesn't accomplish everything
   ChrisL: people think you can fix this by adding more color stops but
           apart from enlarging your code
   smfr: if we're using CoreGraphics which doesn't have this can we support
         this by adding color stops in the UA?
   cabanier: yes
   florian: getting back to Chris' point, you will still have parts that
            aren't smooth
   florian: should we try to solve that in one go?
   cabanier: not really, maybe in the future

   TabAtkins: what would happen if you added multiple midpoints?
   ChrisL: one describes a curve, two or more--the behavior is not defined
           and is not used in practice
   TabAtkins: so more than one would be a syntax error
   ChrisL: yes
   leif: I saw a similar effect when dragging the stop and midpoint to the right
   cabanier: that's due to the response curve since your device is not linear
   cabanier: that requires a different solution
   heycam: we already have that in SVG, you can specify interpolation in
           linear or sRGB
   cabanier: yes
   ChrisL: we don't yet have a way to ask for a smooth curve through points
           in a color space with C1 continuity
   ChrisL: although we do have that for paths now with Catmull-Rom curves
           in SVG2

   RESOLVED: change CSS Images 4's specification of colorless color stops
             to use Rik's proposal (i.e. use power curves)

Filling Text
------------

   krit: we decided we want to have fill/stroke properties on text in
         general, not just SVG shapes
   krit: however, lately we realised we don't just want SVG paint servers
         but also images
   krit: so you can use regular CSS images etc.
   krit: the difficulty comes from referencing images that have fixed size
   krit: if the area you are painting differs from the size of the image
   krit: what do you do
   ChrisL: that problem has already been solved for backgrounds
   krit: yes that is the proposal
   krit: but roc suggested we don't support attachment

   smfr: what is the property?
   TabAtkins: you can use 'fill' etc. on text
   smfr: what is the bounding box
   TabAtkins: I think we were going to use the box of the text?
   smfr: use the background bounding box
   heycam: with the box decoration break, it's not too much trouble to
           paint the text over and over again?
   krit: without attachment you can't simulate some behaviors of
         background-clip: -webkit-text
   smfr: the geometry of the image filling is exactly the same the geometry
         backgrounds will use

   krit: the question here is not so much about painting CSS text but first
         how to use fill/stroke in SVG
   krit: what do we do in SVG for multiple fill layers?
   krit: I would like to use the same syntax as for background but without
         introducing extra properties
   krit: we can do that later
   krit: for now just have the one property specifying the multiple layers

   heycam: what are the different parts of background?
   heycam: if we are going to do some, we should do all?
   heycam: often you want multiple backgrounds so you can layer them all
           at once without doing different sizes
   heycam: do we need that complexity in SVG?
   krit: it just falls out
   heycam: as long as you can re-use your existing background stuff,
           then it's ok
   TabAtkins: do you want to do the same thing for stroke?
   krit: yes
   smfr: so would you repeat the image like we do for backgrounds?
   krit: yes, with the same syntax

   TabAtkins: for SVG we'll ignore the <box> part of the production for
              <bg-layer>?
   krit: not necessarily
   krit: you might want to repeat the image
   TabAtkins: that's <bg-size>
   TabAtkins: the values for <box> don't make any sense for SVG
   TabAtkins: do we want to add the SVG ones there?
   TabAtkins: ('fill', 'stroke') etc.?
   smfr: does fill/stroke just control what gets painted?
   TabAtkins: yes

   smfr: it seems a bit odd, different to what we have in CSS
   smfr: we can't do layered borders
   krit: attachment doesn't make sense for SVG for now so it will just be
         ignored
   krit: we might want to leave it out of the syntax
   heycam: perhaps later we can talk about different stroke widths for
           each item in the list

   smfr: it's interesting that you can do something in SVG that you can't
         do in CSS, namely repeating an image around the border

   krit: I wanted to bring it up today because it's a CSS property and
         because we will use these properties for text in the future
   ChrisL: it is nice for HTML to be able to color text with something
           other than a solid fill
   TabAtkins: we can add attachment later and add it later if we decide
              it is sufficiently useful
   RESOLVED: Import the background shorthand syntax for multi-fill and
             multi-stroke into SVG minus the attachment part of the syntax

Received on Thursday, 20 February 2014 00:20:24 UTC