- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Mar 2016 20:01:05 -0400
- To: www-style@w3.org
- Cc: public-fx@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Masking
-----------
- RESOLVED: Change 'auto' value of mask-mode to 'match-source'.
- birtles will investigate dropping mask-type. If it's not
dropped, he will update the normative text.
Filters
-------
- The authors will keep moving the spec toward CR.
- Tav presented a new filter primitive he'd like added to level 2;
dino agreed it was interesting and will look into adding it to
the spec.
Gradients & Dithering
---------------------
- Either AmeliaBR or Tav will create a proposal to either offer
author control or spec guidance for browsers on dithering.
Investigation about JS API for Realizing Level of Details
---------------------------------------------------------
- stakagi presented some very detailed work he had done (Available
here: https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Investigation_of_APIs_for_Level_of_detail)
- His wiki will be linked to from the spec as a list of things the
spec needs to address.
Transitions and Animations
--------------------------
- Both specs are being worked on.
- dbaron expressed a desire to have help in making progress.
Matrices
--------
- zcorpan requested review of the edits he made in the WHATWG
geometry spec https://github.com/whatwg/compat/issues/19
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2016
Scribe: alancutter & nainar
CSS Masking
===========
astearns: We can go to afternoon topics: dbaron's conflicting
values in mask shorthand.
<astearns> https://lists.w3.org/Archives/Public/public-fx/2015OctDec/0021.html
dbaron: mask properties do something we said we wouldn't do again.
dbaron: I suspect... let me get the spec.
<dbaron> https://drafts.fxtf.org/css-masking-1/#masking
dbaron: The basic problem is the mask's position section (chapter 7)
dbaron: It has a bunch of properties analogue to background
properties and a bunch of new properties.
dbaron: One you have these values...two have an initial value of
auto.
dbaron: Makes parsing shorthand painful.
dbaron: Change mask shorthand to anything that is not value of
other properties.
dbaron: Question 1: constrained by compatibility: not do it at
this point
heycam: We might be the only one that do mask-mode.
heycam: Extending mask-mode and mask properties might be two
separate things.
heycam: We should be safe in renaming the initial values, even if
people use mask-mode they probably don't specify the
initial values.
dbaron: So does anyone implement mask-mode? looking at apple and
edge and chromium folks.
dbaron: Less looking at chromium.
eae: We don't implement mask-mode.
eae: We do not implement.
heycam: WebKit does not implement it?
heycam: Gecko has patches on nightly but not on other channels.
dbaron: Mask-mode was done a year ago - separately from other
properties and is shipping.
astearns: Are you concerned with existing content?
astearns: ok with getting other values?
astearns: Mask-mode should not have a value called auto?
dbaron: mask-mode is part of mask shorthand
dbaron: I'm pretty sure cjs patch added a mask property
heycam: I would be pretty surprised if we couldn't change the
initial value names.
dbaron: Question - initial value for this property that isn't auto
heycam: This is the value that means...
astearns: either luminance or...
<AmeliaBR> "auto" means luminance for <mask>, alpha for <image>
heycam: or alpha depending on whether we're referencing an SVG ?
or not?
dbaron: Yeah it really is a value we could auto - doesn't belong
in shorthand where it also has value auto.
astearns: It's better to change this than the mask-size property
as that's following background-size.
dbaron: Correct.
dbaron: webkit implements...
AmeliaBR: normal acceptable synonym to auto
dbaron: Webkit implements a bunch of these but not the mode
property.
dbaron: Check that there isn't a normal in these other properties.
heycam: It looks like the property got renamed at some point. When
we shipped it it was called mask-type.
dbaron: The spec has both mask-mode and mask-type.
dbaron: Now we have mask-mode as well.
dbaron: In S 9.2 has a mask-type with values luminance and alpha;
dbaron: in S 7.1 mask-mode has values luminance and alpha.
AmeliaBR: The different is make-type is on the <mask> element and
mask-mode applies on the element you're masking.
fantasai: We probably don't need both.
fantasai: Makes a lot of sense - mask-type was for backwards compat-
fantasai: otherwise could give it a different name.
AmeliaBR: It's something requested of SVG a lot, possible
introduced in SVG1.2 and wasn't in SVG1.1.
heycam: Seems like it is safe to rename.
astearns: Shall we resolve to fix this in some unknown feature
solution?
dbaron: We need a name sooner rather than later - need to ship this.
dbaron: Others haven't implemented mask-mode
shepazu: Do you have a suggestion?
dbaron: Normal works, by-type or by-image?
dbaron: Or something like that.
<fantasai> match-source?
<fantasai> like match-parent?
AmeliaBR: If you're going to keep mask type-then mask-mode should
account for the mask element itself might have a
preference?
AmeliaBR: The logical would be something like use-source or
use-element.
AmeliaBR: If it's an image use alpha.
AmeliaBR: If they both exist then the default value of mask-mode
is to use the mask type of the mask element.
astearns: In example 9 it shows how you would use mask-mode to
override mask-type
astearns: not just a mistake of realizing the other was in spec
already.
fantasai: I think mask-type was added because it existed somewhere.
birtles: I might have added it.
AmeliaBR: It definitely used to have a default override.
AmeliaBR: The wording of it, if using a word other than auto
should use a word defined in the source.
birtles: Added both properties - added mask-type first as authors
wanted to specify..later added mask-mode..don't need
mask-type
birtles: Content should interpret luminance/ alpha values
birtles: introduces complexity.
birtles: Order by-type source-type makes more sense when referring
to image 8.
fantasai: We could do match-source.
<astearns> +1 for match-source
birtles: We probably introduced mask-type as an attribute at first
and it became a presentation attribute.
birtles: Probably can drop it.
astearns: mask-mode would still need that value
astearns: not a replacement.
astearns: Like source-type as a value.
RESOLVED: Change auto value of mask-mode to match-source.
birtles: If we don't drop mask-type .. the example is right, it
follows the mask-type of what it's following but the
normative text says to use luminance if referring to an
element.
astearns: Can we put an action on you to update example and
investigate that mask-type can be removed.
dbaron: Update normative text.
birtles: If we don't need mask-type we should just drop it.
birtles: If we don't drop it, update normative text.
astearns: Are we set for that topic then?
dbaron: As far as I am concerned.
ACTION birtles: Investigate dropping mask-type property
<trackbot> Created ACTION-756
astearns: Next topic: Transitions in animations
birtles: Can we do that after lunch?
astearns: After lunch, sure, after lunch.
astearns: Let's start on filters.
Filters
=======
Spec Status
-----------
<Tav> http://tavmjong.free.fr/SVG/FILTERS_SYDNEY_2016/
Tav: The first part, I want to understand CSS's status, what plans
are there to get this to CR?
Tav: It hasn't been updated since 2014, anyone know what's
happening?
Tav: Anyone working on it?
fantasai: Who is editor?
Tav: krit.
<astearns> (and Dino)
ed: I'm also one of the editors - close to moving to CR.
ed: There might be a few ...
fantasai: Test cases are a CR issue, not a moving to CR issue.
dino: I'm also one of the editors. Maybe I could push the last
three issues along.
Tav: That was the first thing.
dino: Apple would like to see this go forward.
dbaron: We have a bunch implemented and it's shipped.
<AmeliaBR> Firefox & Edge have shipped, Chromium still uses
prefixes
Tav: I think chrome has it for HTML but not SVG.
dino: WebKit is interested in pushing this to CR. I'll take over
the editing.
Filter Primitive
----------------
Tav: I have a filter primitive that I'd like to see added to a
level 2.
hober: What does that mean?
<ed> https://drafts.fxtf.org/filters-2/
Tav: I'd like to see an additional filter primitive but not as
part of level 1.
dino: Sure, yeah, we have all already agreed that this is what we
will push to CR - when you say new primitive
dino: We not might not necessarily mean a new CSS shorthand right.
Tav: Not a shorthand, an actual primitive.
Tav: We have a lot of filter primitives that Apple would like to
see in our native apps.
Tav: We've held off - waiting for other implementations to catch up.
Tav: You'd be interested in level 2?
astearns: There already is a level 2 document.
astearns: Already a document that is L2.
dino: That describes backdrop filters.
dino: It's in a limbo where Webkit has a proprietary
implementation. There's discussion to move it to a new
syntax...
<AmeliaBR> This email should turn into an issue on Filters 1 spec:
https://lists.w3.org/Archives/Public/public-fx/2016JanMar/0020.html
Tav: OK so that covers the first item.
Tav: We (InkScape) have gotten a lot of complaints about uncanned
filters.
Tav: Some of them try to make things look 3d
Tav: There are a lot of artifacts - this is a result of lighting
filters of images using 3 filters channel.
Tav: Get large steps generated by Gaussian blurr,
Tav: There are only 8 bits per channel that causes large steps.
Tav: You can see that what you want is a red line - you get a
black line.
Tav: That produces artifacts. F3 shows that where instead of using
an internal bump map you use external one.
Tav: One of the issues in 22950(?) all the ranges should be
between 0 and 255 or 0 and 1.
Tav: In spec if we state between 0 and 1 allow floating point
value - more bits to work with.
Tav: A quick scan of spec shows that FE filter primitives use 0 to
255 - need to be changed.
Tav: Idea is to allow more bits basically - to go into these
calculations.
dino: Sounds like a good idea that needs investigation.
dino: Need to fix it.
Tav: So basically you'll take on the job of finding out what's
required?
astearns: Amelia suggested on irc that this should be an issue on
level 1.
Tav: That's what I had for filter issues.
dino: Yes, I think you weren't here for discussion on colors
Gradients & Dithering
=====================
dino: Can we talk about positions in gradients, we get complaints
about banding in gradients.
dino: We have hardware that supports more colors we would like a
way to specify colors and see less banding.
Tav: You do dithering or something?
dino: Actually I was always wondering why we don't have dithering
for gradients.
dino: Why don't we specify for css gradients (and svg) add noise
of dithering to not see banding.
Tav: We've gotten complaints about that, people won't use Inkscape
because of banding or they use workaround to add the noise
themselves.
dino: Right, it would be good if leaverou was here - she would
complain about it.
dino: We have a pretty easy solution - no one has suggested we do
it.
shepazu: I have a suggestion.
Florian: Is dithering difficult to implement?
<AmeliaBR> I don't think there is anything in the spec that
prevents implementations from using dithering
dino: On apple platform not easy for us to do.
dino: We will try to find a way to do it.
Tav: We rely on a library and we're thinking of adding it to the
library.
Tav: What would be a way forward for dealing with this?
dino: Someone should make a proposal to the mailing list or I
mean...then we can have the discussion on how to add it to
gradient syntax.
dino: Implementation should do it by default.
dino: There will be cases where an author wants dithering - css
gradients are using it to stripy lines gradient effects
dino: in a gradient.
Tav: How do you do checker boards? Oh lots of stops I see.
AmeliaBR: It's already an issue whether implementations alias or
not before you get to dithering comes in.
AmeliaBR: Some implementations don't alias the edges of
vertical/diagonal stripes.
AmeliaBR: That can create fuzzy edges on ... stripes.
AmeliaBR: There's already a variety of implementations.
Florian: As for dithering breaking these use cases - do the
dithering carefully
Florian: can do it in a way that doesn't break it..
Tav: Did that use enough time?
dino: So who is going to make this proposal, do you want to make
it Tav?
Tav: I could make the proposal.
dino: Maybe AmeliaBR wants to make a proposal to control aliasing -
use different aliasing
dino: I don't know.
AmeliaBR: Talking about having a property to allow author control
or spec guidance for browsers?
AmeliaBR: I'm looking towards making colors as smooth as possible,
use something else for stripes.
dino: ok
Investigation about JS API for Realizing Level of Details
=========================================================
astearns: On to the next thing, we have 30m before lunch.
<stakagi> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Investigation_of_APIs_for_Level_of_detail
stakagi: Please see this wiki.
stakagi: In response to last discussion - next chapter this
assumes content for level of detail.
stakagi: This investigation assumes - it's a characteristic that
sources are embedded - our sources interact with
geographical systems.
stakagi: Must be documented by document object model.
<heycam> stakagi quotes from the wiki page: "The typical form of
the contents which this investigation assumes is as
follows. They are the hierarchical contents by which
tiling was performed for each level of a detail. It is
characteristic that each resources are embedded using
iframe. It is because our usecase is interactive
geographic information system, so graphics must be
operated by DOM."
stakagi: CSSOM build modules and CSS device adaption module 1.
stakagi: Next chapter investigates panning or zooming action.
stakagi: As CSSOM view shows there are two kinds of zooms, page
zoom and pinch zoom.
stakagi: Each browser implements natively.
stakagi: I find CSS device adaptation has called pinch zoom and
magnifying glass type zoom.
stakagi: Page zoom is resize event where it has an issue.
stakagi: The issue describes - pinch zoom picture defines scroll,
they also have issues. For scroll there's a scroll event.
stakagi: APIs for zoom - is next API. One is page zoom there's
device pixel ratio where there's also an issue. Pinch
zoom also has issue.
stakagi: There is device pixel ratio - there is also issues - and
pinch zoom has also issue.
stakagi: <Reading wiki>
stakagi: <Reading "The issues on existing APIs" section>
stakagi: <Reading "Points in question" section>
stakagi: That is my investigation of level of detail APIs.
astearns: Thank you for the investigation - useful info.
astearns: Sounds like something that should go into viewport work
that we are going to do.
Florian: As a co editor of spec I agree there is a lot of
editorial work needed to clarify the visual viewport.
Florian: Having rewritten and clarified what the various
viewpoints are gives us the various types of zooming.
Florian: For all the points you made about this I agree it's been
a matter of prioritization.
Florian: One thing I disagree on is about transform.
Florian: Maybe a discussion would change my mind if transform was
out of scope.
Florian: Maybe discussion is to be had but I think this is out of
scope for transform.
Florian: Had many side list offline discussion about what should
happen to spec - agree to editorial problem.
Florian: I think that what it currently defines is the right
behavior but it should define more things.
Florian: The problem has been having the time to work on it.
Florian: How to make that actually happen - everyone involved in
that spec agrees to the problem.
Florian: I want to, but have other things to do first.
Florian: Matt from Microsoft has been added as a coeditor.
Florian: I would be surprised if he disagrees but probably is busy.
Florian: Same for Rune from Opera.
Florian: Except for transforms, I agree with everything you said.
astearns: At the very least we should take this report as an issue
(several) things to work on
astearns: in that spec.
Florian: I would rather add one issue that points to the entire
report instead of slicing and possibly missing things.
astearns: It records that it's something that needs looking at at
some point in time.
Florian: There is substantial overlap with an article and what he
is saying.
Florian: We can have both issues and both reports, they're asking
for the same changes to the spec.
astearns: I recall that we talked about having a new document that
defined viewport better
Florian: The document we talked about assigned to Peter, Rossen
and I is fuzzy about the viewport.
Florian: It's the thing around the root.
Florian: We may find that it's the missing thing or we won't it's
not clear.
Florian: Once the other spec starts existing maybe some pieces can
shift between the two.
astearns: Is there anything you wanted to talk about on this topic?
stakagi: Can I help your work? <points to Florian>
Florian: I want to answer yes but I'm not sure how.
Florian: I would like detailed issues about - but before that I
think we'd need a rewrite to get consistent vocabulary.
Florian: Even though the end result is correct. Maybe I'll add an
issue in addition to the report that there should be an
API for this.
Florian: We could file an issue about the vocabulary, it needs a
general overhaul.
Florian: I have very little or no time to work on this.
Florian: Thanks for the offer of help.
astearns: Alright then , break for lunch - come back for one
remaining agenda item
Best Practices
==============
fantasai: BTW I'm doing a talk on best practices on CSS, if you
have anything you want to convey to the web authors
let me know.
fantasai: "Use shorthands to reset things because they will reset
all the things"
dino: Don't use index over 999, anything below that is fine
dino: use SASS
<franremy> fantasai: use grid or flex not floats for grids
astearns: Let's lunch
Transitions and Animations
==========================
Scribe: ewilligers & alancutter
astearns: The last item is a discussion of transitions and
animations.
astearns: Path and obstacles to CR.
dbaron: I'm hoping I'll get time to edit the path spec/transitions
spec. It's hard to make promises.
dbaron: If someone wants to help that will be useful but I'll try
to make progress.
birtles: Working on css animations, made some edits,
astearns: Does anyone want to have a deeper discussion about the
path to CR?
<AmeliaBR> Can anyone say what the obstacles are?
Matrices
========
astearns: So we have an update that Simon wanted to give.
<zcorpan> https://github.com/whatwg/compat/issues/19
zcorpan: In the geometry spec there's an interface for matrices.
I've made some edits to make it incompatible with CSS
Matrix.
zcorpan: This is FYI, please review.
zcorpan: In particular that I didn't break compat.
zcorpan: As part of this a few methods were dropped because they
were the same as some other methods.
zcorpan: Please review if there's a use case for them and we
should add them back.
<astearns> https://drafts.fxtf.org/geometry/#changes
heycam: I'll compare it with SVG Matrix.
Summary of Scrolling Breakout
=============================
astearns: Can we get a summary of the scrolling discussion?
astearns: I am interested in what happened during breakout.
shane: The full minutes are available on public-fx.
shane: We talked about scroll triggered animations and parallax
ideas that were brought to TPAC before last.
shane: There are potential problems with animations re-triggering
themselves but overall there's a fair amount of interest
across browsers
shane: to get this area specified.
shane: Next steps is dino will write an explainer document
shane: We will be very interested in people asking questions,
making suggestions and bashing on it.
<zcorpan> log: http://www.w3.org/2016/02/02-fx-irc
astearns: That exhausts agenda
astearns: We are adjourned but we have time to keep working
together.
astearns: And there is the event tonight.
shane: We have 5 talks scheduled: best practices, css grid,
houdini, round displays, new features in svg 2
shane: There are 180 developers of all stripes signed up to show.
shane: Please come tonight and show who you are, it's an excellent
opportunity to meet the people you're building features for.
Please come.
shane: In this room at 6:30
astearns: Adjourned.
astearns: <Hammer>
Received on Thursday, 24 March 2016 00:02:07 UTC