W3C home > Mailing lists > Public > www-style@w3.org > March 2015

[CSSWG] Minutes Sydney F2F 2015-02-11 Part II: Filter Effects, CSS Blending, Colored Font Palette Control, text-rendering

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 20 Mar 2015 02:40:46 -0400
Message-ID: <CADhPm3tQFrz3MLydGKQr0tRd=4u9gyUg3R3DR19U766XnG8A1g@mail.gmail.com>
To: www-style@w3.org
Filter Effects
--------------

  - RESOLVED: If a filter references a missing ID or an element that
              is not a <filter>, the element is rendered normally as
              if filter:none
  - RESOLVED: If a filter primitive references an invalid input,
              then the whole filter is disabled and the element is
              rendered normally.
  - RESOLVED: Defer context-fill usage in Filter-specific properties
              until level 2 of Filters.
  - RESOLVED: The feColorMatrix pre-defined matrices should all use
              4 digits after the decimal point.
  - RESOLVED: Make it clear that em units on filterUnits-affecting
              attributes are resolved against font-size on the same
              element; and we'll add a note mentioning that it won't
              do anything useful for you (unless you use very small
              em values of course).
  - RESOLVED: Publish a CR of Filters spec (under the new process).

CSS Blending
------------

  - The CR must last until at least 17 March so Blending couldn't go
      to PR during the F2F.
  - There was concern about the tests not applying to SVG elements,
      so the editors will produce SVG versions of the tests.

Colored Font Palette Control
----------------------------

  - RESOLVED: Add font palette selection to CSS Fonts level 4.
  - RESOLVED: We add custom palette support without the @font-
              palette rule.
  - RESOLVED: font-palette property will have light and dark
              keywords to select the first light or dark annotated
              palette in the font.

text-rendering
--------------

  - RESOLVED: text-rendering:geometricPrecision will require that
              font metrics and text measurement will be independent
              of the device resolution and zoom level.

====== FULL MINUTES BELOW =======

  Scribe: heycam

Filter Effects CR
=================

  <plinss> http://dev.w3.org/fxtf/filters/issues-lc-2015.html
  <dbaron> or alternatively http://drafts.fxtf.org/filters/issues-lc-2015.html
  krit: This is the disposition of comments document:
  <krit> https://github.com/w3c/fxtf-drafts/blob/master/filters/issues-lc-2015.html
  krit: We have some open issues still in the spec.

Filters with Errors
-------------------

  <krit> http://dev.w3.org/fxtf/filters/issues-lc-2015.html#issue-4
  krit: One of them is error handling in general with filter effects.
  <krit> http://fiddle.jshell.net/ev10jtmp/3/
  krit: Here's (above) a test for error handling.
  krit: The filter property can take a url, which references a
        <filter> element,
  krit: what happens if the url is invalid.
  krit: If it's invalid then I think it's clear that we should
        ignore the setting of the filter property, and fall back to
        the default.
  krit: That's standard CSS behavior.
  krit: What if it's valid syntax but does not reference a filter,
        or the ID doesn't exist?
  krit: Behavior is different between browsers.
  krit: SVG 1.1 said that the filtered element disappears.
  krit: There were objections that this might not be the preferred
        behavior.
  krit: Firefox does what SVG 1.1 says, so if you apply filter:url
        (#badID) then it makes the object disappear.
  krit: Other browsers ignore the filter.
  heycam: I think Firefox should display the element normally, i.e.
          ignore the filter.

  RESOLVED: If a filter references a missing ID or an element that
            is not a <filter>, the element is rendered normally as
            if filter:none

  krit: The next problem is, what happens if the URL is valid, you
        reference an element, it exists, but now you have certain
        filter effects in it and they take an input that doesn't
        exist.
  krit: e.g. <feGaussianBlur in="invalid">.
  krit: SVG 1.1 makes the whole filtered element disappear.
  krit: WebKit does that, as Firefox does.
  krit: Blink does something different.
  krit: Or you could reference the previous filter effect (i.e.
        default in="" value) or default SourceGraphic.
  dino: Or make the primitive use transparent black as input.
  roc: Yes.

  krit: If you make a mistake in the filter chain, it's not going to
        give you a result you want.
  krit: If you reference a filter input that doesn't exist, that
        could kill the whole processing of the filter.
  krit: I don't think we should just make transparent black for that
        primitive's input.
  <liam> [having the element not rendered means you can't easily
         right-click on it and "inspect" to debug the problem]
  Tav: I agree with that.
  nikos: Making just one primitive's input transparent black can
         help you understand where the error is.
  ed: I think what Presto is doing is following the 1.2T model,
      which says to take the default value if you have an error in
      an attribute.
  krit: Which would be the previous filter effect.
  heycam: I'm fine with disabling the filter.

  RESOLVED: If a filter primitive references an invalid input, then
            the whole filter is disabled and the element is rendered
            normally.

currentColor in feColorMatrix
-----------------------------

  <krit> http://dev.w3.org/fxtf/filters/issues-lc-2015.html#issue-6
  krit: Next, issue #6
  krit: If someone uses currentColor in feColorMatrix, what is it?
  krit: The proposal is to have currentColor resolve against the
        element that is being filtered, not with the value of color
        on the actual primitive element.
  Tav: We have context-fill.
  Tav: We decided to make that work in all referencing elements,
       like filter, pattern, etc.
  krit: I'd like to delay putting anything in the filters spec for
        this.
  ed: I think that's fine with me.
  heycam: Happy to do that later.

  RESOLVED: Defer context-fill usage in Filter-specific properties
            until level 2 of Filters.

Better Precision for Color Matrix Values and Luminance
------------------------------------------------------

  <krit> http://dev.w3.org/fxtf/filters/issues-lc-2015.html#issue-8
  <krit> http://dev.w3.org/fxtf/filters/#element-attrdef-values
  krit: Next is issue #8
  krit: Luminance has fixed color matrix values. In most places they
        have 3 digits after the dot, in some places they have 4.
  krit: The request was to have 4 digits everywhere, instead of just
        3.
  heycam: So it's using 4 digits in the luminance matrix, but 3 in
          the other types.
  krit: Any objection to using 4 digits everywhere?
  (none heard)

  RESOLVED: The feColorMatrix pre-defined matrices should all use 4
            digits after the decimal point.

Resolving Units when filterUnits="objectBoundingBox"
----------------------------------------------------

  <krit> http://dev.w3.org/fxtf/filters/issues-lc-2015.html#issue-11
  krit: Next, issue #11.
  krit: If you have objectBoundingBox units, and you try to use say
        47em, what does that mean?
  krit: It's not clear what element the ems are resolved against to px.
  heycam: I guess they should be resolved against the font-size of
          the element they're on.
  ed: I'm not sure if this needs to be mentioned in the spec.
  ed: We could put a note that these values will give useless
      results [as they're much > 1].

  RESOLVED: Make it clear that em units on filterUnits-affecting
            attributes are resolved against font-size on the same
            element; and we'll add a note mentioning that it won't
            do anything useful for you (unless you use very small em
            values of course).
  <liam> [the note should explain why, as there are cases where it
         works]

Confusion over the specularExponent attribute
----------------------------------------------

  <krit> http://dev.w3.org/fxtf/filters/issues-lc-2015.html#issue-12
  krit: finally, issue #12
  krit: I thought we already discussed this and decided.
  Tav: specularExponent is used in two different places.
  Tav: Just adding a note to say that two uses of this are different.
  krit: I think I made that change already.

  krit: Now, how do we want to proceed with the spec? Should we
        continue with a WD or should we publish a CR of it?
  ed: Any objections to publishing as CR after the edits are done?
  (none heard)

  RESOLVED: Publish a CR of Filters spec (under the new process).

CSS Blending PR
===============

  krit: I'm speaking for Rik who can't be here.
  krit: We already had a resolution to PR at TPAC, but there was one
        issue that forced us to have another CR.
  krit: There haven't been any complaints since then.
  krit: Rik is working on the necessary documents to get to PR, and
        I'd like to have the resolution from the WG to go to PR.

  ChrisL: Implementation report with two passes for everything?
  krit: We do have 2 implementations for each feature and Rik is
        preparing that implementation report.
  ChrisL: Shouldn't need a resolution of the WG.

  Florian: We could resolve that we think the test suite is
           sufficiently extensive.
  Florian: That passing it is meaningful
  Florian: and then we you pass it everything is fine.

  ChrisL: What's the test coverage like?
  Tav: including SVG?
  krit: Yes, we have tests covering each section.
  <krit> http://test.csswg.org/suites/compositing-1_dev/nightly-unstable/report/
  krit: The other part of the test suite are the canvas tests that
        were published with Philip's test suite.

  ChrisL: What do the CR exit criteria say?
  <plinss> http://www.w3.org/TR/compositing-1/#cr-exit-criteria
  ChrisL: The SotD section says that CR must last until at least
          March 17.
  <plinss> http://test.csswg.org/harness/results/compositing-1_dev/grouped/

  Tav: You have some SVG specific tests, but you don't test each of
       these things in both HTML and SVG?
  Tav: It'd be nice if each of these actually linked to the tests
  krit: I will ask Rik to provide the necessary documents.

  ChrisL:It looks like they're all HTML tests?
  Tav: I am concerned we're not testing enough applying to SVG
       elements.
  ChrisL: There are some broken links too.
  <ChrisL> links like ../support/* should be support/*

  Tav: It would be good for pure SVG documents so I can provide
       results for Inkscape.

  ACTION: Dirk to ask Rik to produce SVG versions of the blending
          tests.
 <trackbot> Created ACTION-89

Colored Font Palette Control
============================

  scribe: Cyril

  heycam: I sent an email to www-style about this
  <heycam> https://lists.w3.org/Archives/Public/www-style/2015Feb/0211.html
  heycam: In the latest version of the OpenType spec
  heycam: which reached a stage where only editorial changes can be
          made
  heycam: there is 3 types of colorful glyphs:
  heycam: Bitmap format like PNG
  heycam: Vector format reusing existing glyf and cff table glyphs.
  ChrisL: Was it extended to CFF?
  heycam: It was an assumption
  heycam: but it might not be.
  heycam: And the 3rd option is embedded SVG document.

  heycam: In the last 2 options they have the option of using a
          palette.
  heycam: In fact for option 2 it is mandatory.
  heycam: For SVG glyphs it is an option by using CSS variables.
  heycam: Some CSS variables are defined automatically.
  heycam: In the font you can define a number of palettes
  heycam: but there is no way to select the palette you want
  heycam: or provide your own custom palette.
  heycam: I thought it might be a good thing to allow.
  heycam: My email has an actual proposal.
  heycam: For selecting which palette, there would be a new property
          font-palette referencing the palette by a name.
  heycam: There is no name in the font.
  heycam: The idea would be to map indices to names for a particular
          font.
  heycam: You don't want to set font-palette: 3 and then depend on
          the font.
  * liam thought it was a good proposal
  <TabAtkins> liam, agreed.

  dino: I think for these fonts, you know what you're doing.
  ChrisL: We don't know what fonts you have on the machine or what
          fonts are downloaded.
  roc: There is an issue with editable content, it is easy for users
       to add characters that are not in the font
  roc: and you can have fallback to system fonts and that might not
       be what you want.
  <liam> [that's true for any font, including woff]
  <ChrisL> we already have that issue with font feature selection,
           where feature numbers are not portable across different
           fonts

  dino: The theory is that if you specify the palette you end up
        with a font that has the right palette?
  heycam: jdaggett was of the opinion that it should go in font
          feature values.
  dino: it's not a big deal but it might be longer to specify.
  dino: People might end up with names 'one', 'two' ... for the
        palettes.
  <liam> [could some suggested names be proposed for palette
         entries? e.g. highlight, shadow, front, layer1, layer2 ? We
         don't have CSS rules that are conditionally applied
         depending on which font is in use]
  heycam: If people were happy with disabling palette selection if
          you use a fallback selection, I'll be happy.

  dino: TabAtkins's suggestion is good too.
  dino: You can use palette name but if the name is a number that's
        the index then.
  roc: We could disable fallback for now and add it later.
  TabAtkins: Reasonable.

  heycam: Do people think this should be in the next level of the
          font spec?
  ChrisL: It doesn't make sense to put in the current level because
          it's stable.
  heycam: What about adding font palette selection to level 4
  heycam: and it uses an index to begin with and font fallback
          disables selection
  heycam: and later we can add a more detailed feature?
  TabAtkins: Yes.

  RESOLVED: Add font palette selection to CSS Fonts level 4.

  ACTION: jdaggett to add font palette selection to CSS Fonts
          level 4

  heycam: The next step, if we want to, is to specify custom palette
          values.
  heycam: For my example (in the email), the font creator would
          provide different fonts.
  heycam: It's normal to have a choice to select the palette.
  heycam: In my optional proposal #2, I added something similar.
  heycam: It adds a @font-palette.
  TabAtkins: I don't think we need the indirection of the @font-
             palette.
  TabAtkins: We can use directly the font property to specify the
             color palette.
  TabAtkins: For colors, giving a name is useful.
  ChrisL: People asked a long time ago to be able to name colors.
  heycam: I'm happy with not having the named palettes and not
          having the @font-palette rule.

  heycam: Does the order of the names and colors in the font-palette
          property have to match the indices?
  TabAtkins: No.
  heycam: What happens if you miss out one of the palette entries?
  ChrisL: You default to transparent black?
  TabAtkins: No, simply black.
  ChrisL: I agree I made a big mistake here.

  heycam: Do we agree we want the feature?
  Tav: Yes.

  TabAtkins: Why don't overload the color property?
  TabAtkins: You might to use a palette function.
  heycam: What does fill=currentColor on a shape if you have that?
  ChrisL: Color can be used for other usages: stroke, fill, ...
  TabAtkins: Yes.
  ChrisL: Not objecting but concerned about how it would evolve.
  TabAtkins: So if you omit some palette index names, we could
             default to using the color value.
  ed: Is it possible to use a palette and override some colors?
  ChrisL: Palette is a preset, you can override it all.
  ChrisL: We've had that discussion on gradients, overriding some
          stops, but it's not used.
  [ChrisL digresses on Web audio]

  RESOLVED: We add custom palette support without the @font-palette
            rule.

  <TabAtkins> Assuming that duplicated palette index names take the
              last one, you can always store a palette in a custom
              property, and override individual bits by putting them
              at the end, like "font-palette: var(--my-palette),
              highlight white;"
  heycam: We'll still name the individual palette entries inside
          font-feature values.

  heycam: The final part in my email, proposal 3:
  heycam: You can specify if one of the predefined palette is
          appropriate for dark, light, both or neither background.
  heycam: Emoji fonts have dark versions and light version.
  heycam: I'm suggesting adding keywords to select the version.
  TabAtkins: +1
  TabAtkins: I'm suggesting to name it according to the system it is
             supposed to be used: lightSomething, darkSomething.
  heycam: You probably always want to use the high contrast one
          without analyzing the background color.
  heycam: I'm ok with starting with just light and dark.
  heycam: Do people agree?
  ChrisL: Yes.
  RESOLVED: font-palette property will have light and dark keywords
            to select the first light or dark annotated palette in
            the font.

  heycam: I'd like to bring a little Issue regarding CSS variables.
  heycam: I tried to implement CSS variables and palettes.
  heycam: [explaining something about caching]
  heycam: We could need a non-variable way to indicate palette.
  heycam: I don't know if we can do that.
  heycam: It's a bit late in the open type process
  heycam: but we might have this problem in other contexts.
  TabAtkins: For SVG fonts, I see the problem
  TabAtkins: but using variables in UA specific way is a violation
             of the spec anyway.
  heycam: It's probably possible to detect that the palette
          variables are used in a sensible way
  heycam: but I'm concerned more about the general pattern.
  heycam: Like a stroke-width controllable by variables.

text-rendering
==============

  Scribe: heycam

  roc: This is a Google request.
  roc: We got an email from docs people complaining that in Firefox
       when you zoom the page in Google docs, the layout of the text
       changes.
  roc: The width of the string in CSS px changes when you zoom
       in/out of the page.
  roc: It turns out this is true in all pages, including chrome in
       some situations.
  roc: The reason is because of font hinting, in this case.
  roc: There are some other issues.
  roc: With vertical metrics it can also occur if you round line
       height to pixels.
  roc: They saw this as a bug, though I don't think it is a bug.
  roc: Generally you do want to hint on windows, as you want to
       match OS text rasterisation.

  roc: Basically, after a short discussion, we determined that the
       right thing to do would be to make text-
       rendering:geometricPrecision disable hinting and try to make
       sure we just use the metrics in the font
  roc: and render that font with no regard to what the device
       resolution is.
  roc: Then if we do that consistently we can make text rendering
       device resolution independent
  roc: and as you zoom in/out you'd get the same metrics.
  roc: Apparently chrome has or will do this.
  ChrisL: That seems consistent with what geometricPrecision was
          designed for.
  roc: If we do this, then the spec should make this a requirement.
  roc: This would apply to HTML and SVG.

  Rossen: When you say zoom, what do you mean?
  Rossen: User zoom in Firefox?
  roc: A full page zoom that causes a layout.
  roc: Ao for any layout-changing zoom
  roc: (non-layout-changing zoom already doesn't affect text metrics)
  Rossen: So this would affect high dpi devices, you're opting in to
          some level of zoom?
  roc: Right now you can get different layout on high/low dpi.
  roc: This would make those layouts consistent with each other
  roc: and across the web.
  roc: We could make layouts fully consistent across browsers, at
       least text width.
  Rossen: I think Ted and Matt Rakow want to make that happen.
  roc: In Firefox I would make text metrics include advance widths
       depend only on the content of the OpenType font.
  roc: The problem is platform APIs apply rounding in different
       situations.
  roc: I'd like to bypass that and just get data from the font.

  Rossen: Do you have any test cases we could look at?
  roc: I'll send you one.
  roc: I should mention that our plan is to continue to render
       glyphs with subpixel AA where possible
  roc: even though we're not doing any hinting.
  roc: This doesn't mean we need to turn off subpixel AA.
  roc: It's a layout issue, not glyph rendering issue.
  roc: Sounds OK?
  ChrisL: Yes.
  dino: Yes.

  RESOLVED: text-rendering:geometricPrecision will require that font
            metrics and text measurement will be independent of the
            device resolution and zoom level.

  ACTION: Cameron to make text-rendering:geometricPrecision change
  <trackbot> Created ACTION-90

  -- lunch break, 90 mins --
Received on Friday, 20 March 2015 06:41:13 UTC

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