W3C home > Mailing lists > Public > www-style@w3.org > December 2013

[css-masking] Comments

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 11 Dec 2013 02:46:31 -0800
Message-ID: <52A84287.5080900@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
[Sorry for the late response. I haven't felt like working lately.]

Non-editorial:

   1. I'm wondering if the naming of the properties should follow the pattern
        mask-x shorthand with mask-x-* longhands for layered masks;
        mask-y shorthand with mask-y-* longhands for box-image masks;
        mask-type not prefixed by x or y since it's not part of either set;
        x and y as, preferably, a single word
      since this would best reflect the relationships among the properties.

   2. Would like to see 'mask-box-image' shortened to 'mask-box' (or some
      other short alternative) as was mentioned in this thread:
        http://lists.w3.org/Archives/Public/www-style/2013Jun/0599.html
        http://lists.w3.org/Archives/Public/www-style/2013Jun/0634.html
      because it's imho unnecessarily long.

   3. In the definition of 'no-clip'...
        # The painted content is not restricted (not clipped).
        # The mask painting area is set to the bounding client rect.
      I don't think this is what we want. Various effects are drawn
      outside the bounding client rect, for example box-shadows,
      border-images with outset, and content that overflows the box.
      If the intent is that the painted content is not clipped, then
      this definition is wrong.

   4. The reference boxes for masking and clipping seem to be
      dramatically different. Afaict, masking uses the boxes as
      defined for backgrounds and borders. But clipping uses the
      "bounding client rect".

      Consider a box that has been split across three columns of a
      multi-col element on one page and into the first column on a
      second page. If I use an elliptical mask stretched to 100%,
      then the clipped perimeter will be an ellipse stretched across
      the height of the reconstructed box, and split across the
      fragments. But if I use an elliptical clip-path stretched to
      100% this will not be the case. If the element stretched just
      across the first 3 columns, then the elliptical clip-path would
      stretch across the rectangle containing the 3 columns. Across
      pages, I don't even know what would result...

      Using the same shape for a mask and for a clip-path should
      result in the same effect.

   5. clip-path should not be defining the origin and percentage
      basis of <basic-shape>s directly, but define what the
      "reference box" is.
        http://www.w3.org/TR/2013/WD-css-shapes-1-20131203/#reference-box

   6. # If the URI reference is not valid [...], no clipping is applied.
      Please clarify whether a stacking context is still created
      or whether the behavior is equivalent to specifying 'none'.

   7. clip-rule is not defined. At all. There's some syntax, an explanation
      of how the two values differ, and an example, but no definition
      of what the property actually *does*.

   8. Does 'mask-source-type' apply to 'mask-box-image-source'?
      It's not clear from the spec. (See editorial issue #8, of
      which this seems to be a symptom.)

    If it doesn't:
      8.A.1 Having its name match mask-x-type per issue #1 would
            help clarify that relationship.
      8.A.2 This raises the issue of whether we need a mask-y-type.

    If it does:
      8.B.1 I should be pulled out into the same section as the
            'mask' shorthand, since they both apply to both types
            of masking.
      8.B.2 Also, in this case, I'd like to reraise the question of
            whether mask-source-type and mask-type should be merged.
            I think it would be less confusing if there was just one
            property and its value at the point of application overrode
            its value at the point of source definition, the same way
            the 'width' property does.

Editorial:

   1. I'd like to see mask-type and the <mask> element given their
      own top-level section. They're defining a mask source, not
      a mask application, as the rest of the properties are.

   2. Similarly, I'd like to see <clipPath> and 'clip-rule', which
      (afaict) define a clip "source" given a separate top-level
      section from 'clip' and 'clip-path', which define a clip path's
      application.

   3. Since 'mask' now is a shorthand for both layered masks and
      box-image masks, it shouldn't be under the layered masks
      section.

   4. Layered Masks needs a new name, since at the moment we only
      have one layer. :)

   5. Would recommend shifting clipping above masking, since I'm
      *guessing* we'd prefer people to clip if they can, then mask
      if it's too complicated for clipping, not Mask All the Things.

   6. Intro still needs work. Structure should probably be
        - What is masking and clipping, and why do we care?
          Focus first on their similarities, but also explain their
          differences so we know which one we're interested in for which
          applications.
        - How to clip things with CSS
        - More on Masking:
            - More technical detail on masking, if needed
            - How to mask things with CSS: what is CSS masking able to
              do, and what features do I use to do it?

   7. The terms local coordinate system, user coordinate system, and
      object bounding box units are only used in the definition of
      <mask>. They should be relegated to that section (or merely
      referenced from SVG), not defined up front. The top terminology
      section should be for definitions and concepts used throughout
      the spec, that someone would need to know to understand random
      sections they jump to once through the introductory sections.

   8. The use of 'mask source' and 'mask image' in the spec is confusing.
      There need to be separate concepts for the mask introduced by the
      background-inspired mask properties and by the border-image-inspired
      mask properties. Once these concepts are named, defined, and
      used consistently, we can have a clearer model for understanding
      CSS masking.

   9. The definition of 'clipping path' in the Terminology section is
      more confusing than helpful. Just <dfn> the first instance of
      the term in the Clipping Paths section.

      Similarly, I don't find the definition of 'mask source' here to
      be helpful, and would remove it from Terminology.

  10. # The usage of mask-box-image corresponds to the border-image property
      # of CSS Background and Borders [CSS3BG].

      Except that the image is used as a mask rather than rendered on
      top of the background, right? :) You should say that up front.

  11. # Later versions of this specification may define new properties
      # to enable fine-grained control over the interactions between
      # hit testing and clipping.

      This specification or whatever one ends up defining pointer-events,
      I presume?

Trivialities
------------

   1. "are applied; these effects" -> use a period, start new sentence

   2. "any other CSS effects such as border"... I think "CSS effects"
      here is rather undefined. Can we be clearer what makes something
      part of this class of effects?

   3. Lastly, there's a stray apostrophe after the Value line in
      mask-source-type's propdef table. :)

~fantasai
Received on Wednesday, 11 December 2013 10:47:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:17 UTC