- 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:08 UTC