W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > April 2018

Re: [fxtf-drafts] [css-masking] Define "raw geometry" for `<clipPath>` clipping

From: Dirk Schulze via GitHub <sysbot+gh@w3.org>
Date: Sun, 15 Apr 2018 10:13:56 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-381395093-1523787235-sysbot+gh@w3.org>
Thinking about it more, I think it is a mistake to talk about 1-bit masks in the normative code in general. This is a mistake inherited from SVG.

At the end the main differences between masking and clipping is that the former fundamentally is a pixel based operation. The latter is defining an area. I'd still like to keep this text in as informative note.

To the normative part:
> The geometry of a text or shape defines the "clipping region". The geometry of text or shapes may be affected by CSS properties and settings like (but not limited to) `font-style`, `font-family`, `font-size`, `font-kerning`, `font-weight` or font variants. Neither the fill, stroke nor visual properties like `box-shadow` or `filter` of a text or shape contribute to the geometry and therefore do not contribute to the "clipping region". Specifications defining CSS properties, features and behaviors should normatively state when the specified behavior or feature contributes to the geometry of a text or shape.

IIRC (and I'll check) we should have normative text for `visibility`, `display`, `clip-path` and `transform`.

@AmeliaBR I agree that ideally CSS would define a group of properties and settings that contribute to the clipping region (geometry of the shape). But with the absence of such a definition I think that is the best we can do for level 1. I am not sure if the term "geometry" needs a definition in any W3C spec. CSS and SVG depend on the knowledge of common terms like that.

-- 
GitHub Notification of comment by dirkschulze
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/170#issuecomment-381395093 using your GitHub account
Received on Sunday, 15 April 2018 10:14:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:22 UTC