- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 20 Mar 2015 02:40:46 -0400
- 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