- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 7 Jun 2016 21:25:37 +0300
- To: www-style@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 Color
---------
- There were several actions recorded to make improvements to the
spec. They were to:
- add note explaining a reasonable range for C in lch() to the
spec
- remove commas between in the color() examples
- fix Rec.2020 and Rec2020 to be rec2020, and DCI-P3 P3 to
either (consistently) dci-p3 or p3
- color() fallback should be like font list fallback.
- add a working-color-space at-rule, which affects the entire
document
- The breakout session proposed resolving to publish WD for Color
and MQ4.
- RESOLVED: Do black point compensation when converting from
profile to another.
- RESOLVED: If you accurately describe the output device's color
profile in an @color-profile rule then a sane
implementation will not alter your colors so this is
sufficient as a replacement for device-cmyk in general
and provides a good RGB fallback automatically.
Grid
----
- RESOLVED: Add allowing track list in repeat() and auto-rows
- RESOLVED: Drop named lines specified on the subgrid
- RESOLVED: Publish a new WD.
Flexbox
-------
- RESOLVED: Publish a new CR flexbox.
Inline
------
- RESOLVED: Publish inline
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics
*** Color Breakout Session Minutes ***
CSS Color
---------
Scribe: zcorpan
<ChrisL> https://drafts.csswg.org/css-color/#lab-colors
ChrisL: We've had discussion in the last f2f for things we've
wanted to do.
ChrisL: Apple have fancy screens now and want to take advantage of
that
ChrisL: something something colorspaces.
ChrisL: XYZ is a colorspace that can describe all known colors.
ChrisL: XYZ fails to do white adaptation.
ChrisL: LAB sticks an axis to the white point and if you take a
perfect white surface, that's 100
ChrisL: then two orthogonal channels A and B that correspond to
greenish and yellowish axises.
ChrisL: LAB is useful, you get it in physical measurement devices
etc.
Florian: In the luminosity direction, how white is 100%?
ChrisL: There are different standards for standard daylight and
the one sRGB uses
ChrisL: (before) LAB uses D50
ChrisL: ... this is all just summarizing the spec.
ChrisL: If you look in the spec, I've tried to keep the math to a
minimum.
ChrisL: issue about out of range numbers
ChrisL: steps for how to convert ...
TabAtkins: what is a reasonable range for C?
ChrisL: to go from LAB to ???
TabAtkins: so conversion between a/b and c/h is just rectangular
to polar
ChrisL: this is using the color() function, see example 9
ChrisL: it's like @font-face
ChrisL: you give it a url
TabAtkins: idents is the right thing
ChrisL: ident and then as many numbers as needed
<dbaron> ACTION ChrisL to add note explaining a reasonable range
for C in lch() to the spec
<TabAtkins> https://drafts.csswg.org/css-color/#color-function
<dholbert> (inside of https://drafts.csswg.org/css-color/#icc-colors )
Florian: Why only 2?
ChrisL: sRGB could be added but it doesn't give us anything new.
ChrisL: Happy to add it if people want it.
smfr: Makes sense for consistency.
ChrisL: There's a section about grayscale.
ChrisL: Consider replacing the grayscale section with a grayscale
colorspace.
ChrisL: We had a briefer syntax.
leaverou: What about thing like named color profiles ?
leaverou: Spot colors.
ChrisL: Does not allow overrange values.
ChrisL: We've handwaved about this for a long time.
ChrisL: There was a linear space that was easy.
ChrisL: There's something black that's not absolute black.
ChrisL: That lasted for 2 years and then they decided to use a
wider gamut if you want a wider gamut.
ChrisL: We should have early clipping.
cabanier(?): It's quiet about that.
smfr: Do we want commas?
TabAtkins: No, because we want to allow alpha.
TabAtkins: Need to distinguish.
ChrisL: So no commas between numbers in examples.
<dbaron> ACTION ChrisL remove commas between in the color()
examples
ChrisL: Next section is P3 and Rec 2020.
ChrisL: These refs can be added to MQ4.
<dbaron> ACTION ChrisL fix the currently-broken Rec.2020 reference
in the spec
leaverou: If one is supplied no color profile, it will be ignored?
ChrisL: @color-profile foo icc profile which is treated differently.
leaverou: This might be confusing in some cases.
ChrisL: It will look wrong if you copy a color but not the profile.
TabAtkins: Rec.2020 is not a valid ident.
TabAtkins: Rec2020 works fine.
ChrisL: Thank you, noted.
TabAtkins: Also ascii as lowercase please.
ChrisL: mkay
TabAtkins: Match what MQ does.
<dbaron> ACTION ChrisL fix Rec.2020 and Rec2020 to be rec2020, and
DCI-P3 P3 to either (consistently) dci-p3 or p3
ChrisL: Colors in wide color space and the device with a narrower
space.
ChrisL: What do you do with the ones outside?
ChrisL: If it's an image with a nice gradient, things can look ugly.
ChrisL: You move everything proportionally so that it looks nice
ChrisL: but it's handwaving.
ChrisL: Maintain the relationship between colors but they're all
going to match.
ChrisL: It's fine for a photograph but not when you want to match
up a color in an image with a css color
ChrisL: Saturated is useless.
TabAtkins: Can we drop it?
TabAtkins: Can we only allow them to choose the ones we care about?
ChrisL: yeah... think so
smfr: I don't know if we want to drop absolute color metric, might
be useful for testing
ChrisL: "this has to have an absolute luminance of this"
Florian: If you have several profiles with the same color space?
ChrisL: Last one wins.
TabAtkins: They cascade as a unit
cabanier: This is basically unused. Can we leave it as is?
ChrisL: In svg2 you have to overwrite the profile.
ChrisL: Should we remove the rendering intent thing?
cabanier: Just use the default.
TabAtkins: Need some way to choose the default.
ChrisL: Perceptual is less good for css.
smfr: Why is rendering intent tied to color profile?
smfr: You want to specify rendering intent ...
ChrisL: The way ICC profiles work, is you have a profile for your
source data
ChrisL: then you have a profile for your output device
ChrisL: compose those two.
ChrisL: How are you going to handle out of gamut colors?
ChrisL: If you select perceptual
ChrisL: it's less applicable to a wide gamut screen.
ChrisL: An image has an intent built in;
ChrisL: you can't override it.
TabAtkins: If the profile has multiple intents you can specify the
one you want.
Florian: If the profile has multiple, does it specify the default?
ChrisL: Yeah.
cabanier: We set that as the default in the product.
Florian: It's ok for photos and what we should use for the rest?
ChrisL: Yes.
ChrisL: Named color profiles, instead of having a mapping from a
number.
ChrisL: You have mapping from a name.
ChrisL: People can do their own ones.
ChrisL: This syntax does not cope with that but can be extended to
do so.
Florian: color() function, either a list of numbers or a string
Florian: The other extension is to allow you to name your colors.
Florian: New descriptor, @color-profile foo { src:...;
named-color: "myblue" 00255, ...;
Florian: Maybe not necessary because of variables.
leaverou: Can you rename existing colors?
ChrisL: Yes.
TabAtkins: Don't object but it's strictly not necessary.
ChrisL: I like it but variables is enough.
cabanier: Print with specific ink...
Florian: Can do that with this or with variables
Florian: The variable contains "foo" 00255 so it contains the
right colorspace.
TabAtkins: Are these profiles text files?
ChrisL: No terrible binary files.
ChrisL: Tool to convert to xml so you can hack and convert back.
dbaron: Some security vulnerabilities.
esprehn: Apple have fixed security bugs in icc.
ChrisL: Should restrict to same-origin.
TabAtkins: Web policy, things should default to same-origin.
ChrisL: Why are people using google fonts?
TabAtkins: CORS, no problem
smfr: Before you download you have to wait for ICC to download,
like with fonts.
smfr: Need to describe what should happen before it is downloaded.
smfr: Would not impl except for built-in color profiles.
esprehn: Same for us.
Florian: context-dependent profile
esprehn: Won't implement.
Florian: What do you fallback to?
esprehn: Wouldn't paint, same as fonts.
Florian: So everything's white?
ChrisL: Flash of uncalibrated color.
esprehn: Yeah.
esprehn: I'd like to see that you can specify a name so you don't
need to download if you already have it.
ChrisL: Fonts have local() for that.
ChrisL: Fine to have that here also.
ChrisL: How do you name your profiles, typically don't have a
unique name.
ChrisL: How do i define it?
TabAtkins: Platforms can define what their names are and you can
put it in the spec?
ChrisL: So it's different per platform? -_-
TabAtkins: Here's url, here's hash.
esprehn: Not a security issue, privacy issue.
TabAtkins: Fingerprinting is a lost cause
dbaron: You can binary test for any font.
TabAtkins: Fingerprinting is not fixable.
leaverou: If I'm using super-RGB color space, makes sense to
fallback to sRGB until it's loaded.
TabAtkins: So fallback to a known name?
dbaron: Is there a dictionary of downloadable profiles we can name?
TabAtkins: We can inline them in the spec, they're small.
Florian: Want to point to an image to use it's profile.
ChrisL: We can put an appendix of common profiles.
ChrisL: Print profiles are not small.
TabAtkins: In Houdini we want these to be serializable.
TabAtkins: Represent something in the string OM.
TabAtkins: Here's the profile, it's 700 bytes of chars.
TabAtkins: The color is considered invalid until the profile is
downloaded.
esprehn: Not going to reparse.
TabAtkins: hrm.
TabAtkins: ok nevermind.
ChrisL: If you have a font stack, how does it work when the
primary is downloaded?
esprehn: Recompute, not reparse
TabAtkins: Fallback in color(); fallback is like font list.
esprehn: That's implementable.
TabAtkins: Must provide a fallback.
ChrisL: I'm fine with that.
leaverou: Want to be able to fallback to a different profile.
TabAtkins: That's fine.
TabAtkins: In the color profile rule you can have a list of
fallback profile names.
TabAtkins: Also in the color() function you can have a fallback
color.
cabanier: Have to always specify fallback? no optional, ok.
Florian: Can you use rgba() in the fallback?
TabAtkins: ya
ChrisL: Open issue, blending happens in sRGB.
ChrisL: Which will give you clipping problems.
ChrisL: Also doing maths wrong.
ChrisL: Was going to add linear.
ChrisL: There's hardware support.
ChrisL: You can get the right result with LAB.
ChrisL: We need a thing that says how you composite things.
smfr: Compositing and blending has a similar problem.
cabanier: The gamut is being worked on in the canvas spec
cabanier: need to specify, just 1.
smfr: We can't change the default because that breaks web pages.
TabAtkins: Subframes does it only work for top-most windows?
TabAtkins: iframe
Florian: If it doesn't say but the iframe does, does it propagate
up?
TabAtkins: No. You can have two iframes
smfr: I can't find linear blending in the spec.
ChrisL: It's an open issue.
Florian: When you've done your things in your colorspace, when
you've done it, what do you export it into?
ChrisL: the output colorspace, whatever that is.
ChrisL: LAB is convenient for this reason.
Florian: If you use anything but LAB do you need to go through LAB
first?
ChrisL: Yeah.
Florian: When that's specified, do the color math other than color
blending also happen in that colorspace?
Florian: If we have LAB, can I switch to it and use it for ???
ChrisL: Yes but you get different result.
Florian: Yeah, that's the point.
cabanier: If you render in colorspace then all colors are in the
same colorspace.
ChrisL: I've seen examples of interpolation of ???
ChrisL: Can we pick a placeholder name?
TabAtkins: document-interpolation-color-space
smfr: working-color-space?
TabAtkins: yeah
cabanier: You map your colors so it's fine.
ChrisL: 3x3 matrix
ChrisL: Don't use 8 bits.
ACTION ChrisL working color space
Florian: sRGB?
ChrisL: Auto is sRGB
ChrisL: linear-sRGB
ChrisL: LAB
ChrisL: Any others?
cabanier: The list of working spaces can't include linear?
ChrisL: Why not?
cabanier: Can't implement it yet
ChrisL: That's wrong. HW has it already
ChrisL: Can do it in linear-sRGB with clipping
cabanier: Need to change the blending spec.
cabanier: So the output is bogus?
ChrisL: No, it's wrong now but people are used to it.
ChrisL: Yes you will get a different result, if you're not using
linear space you're technically get the wrong result now.
ChrisL: Additivity...
ChrisL: Measure the light of two lights.
ChrisL: Additivity means I can take the two numbers and get the
right result.
ChrisL: In linear space you get the right result with +, otherwise
not.
Florian: In LAB, linear matches perception, which is nice.
ChrisL: Exactly.
smfr: MQ?
cabanier: Should match canvas.
cabanier: ... p3 2020, optimal (matches the screen)
cabanier: On iMac you would be compositing in p3.
cabanier: The gamut most closely matches the output.
ChrisL: ok so MQ.
Florian: I think what's in the spec now which is TabAtkins's
interpretation of what we had in the mailing list, is
fine with me.
Florian: If people disagree say where and why.
dbaron: This is a new type of MQ.
dbaron: MQ where more than one of the values can be true.
TabAtkins: Yeah all the range based ones have that.
dbaron: It's a set MQ rather than a discreet MQ.
dbaron: Might want to describe as a different type.
TabAtkins: ok
ChrisL: Are they ordered?
TabAtkins: Only range features have an ordering.
Florian: That you can do "less than".
dbaron: Color gamut sRGB means it can do all of sRGB
TabAtkins: Should we add a value for "narrow" for extra-low gamut
(below sRGB)?
dbaron: Concerned whether we CAN calculate it, if we have
information to calculate it.
Florian: Should I load normal images, fancy images or super-fancy
images
leaverou: Percentages seems useful.
smfr: No this is good enough.
TabAtkins: Boolean context are true for anything other than none
or 0
TabAtkins: Not (boolean) is true.
smfr: You're asking about the OS, not the screen.
TabAtkins: It does not talk about the output device, need to fix
wording.
Rossen: Present to projector.
Florian: Two screens?
esprehn: Every monitor has its own profile, if you move a window
between two, we repaint the window, which resolves the
colors again.
Florian: The incentive for UAs to lie is not high, it only makes
you download heavier images than you need.
TabAtkins: If there are multiple screens...
Florian: Why not the highest?
TabAtkins: In general you want the lowest.
TabAtkins: Want to see the same thing as what's on the projector
TabAtkins: below CSS.
Florian: There are objections that this is not restricted to RGB
spaces or the screen media type.
Florian: If you have a whatever colorspace, if it's bigger then p3
then you match.
Florian: People have disagreed with that.
Florian: Maybe add a cmyk.
ChrisL: We have TVs which have ???
Florian: if you have a sucky printer sRGB is what you get.
TabAtkins: We can add specific named variants.
Florian: For UAs that don't output in cmyk, this has 0 impl cost.
TabAtkins: We dismiss the objections and go with the current design.
Florian: Happy with that.
ChrisL: Publish this?
TabAtkins: Intent to publish.
PROPOSED RESOLUTION: publish css-color and mq4
dbaron: There's impl interest for some things but not others.
dbaron: Might be worth trying to figure that out sooner rather
than later.
TabAtkins: Figure out what we want to impl.
ChrisL: color-mod() problems TabAtkins?
<smfr> https://drafts.csswg.org/css-color/#modifying-colors
TabAtkins: 1) syntax is confusing and crappy
TabAtkins: I agree partially
TabAtkins: it's overcomplicated.
esprehn: Aliasing for everything? can we not do that?
TabAtkins: 2) ??? is not super useful for real-world stuff
TabAtkins: Modifying one color...suggested some different
operations that I want to put in here instead.
TabAtkins: Replace this with something like blending two colors
together.
leaverou: Lightness or mix with white and black which works better.
TabAtkins: Color blending, color contrast, tint and shade.
leaverou: I implemented a polyfill, it occurred to me that there
were lots of (((()))) like lisp.
TabAtkins: The grammar is intended to reduce that.
leaverou: I suggest keywords.
TabAtkins: I agree.
leaverou: Crazy idea, what if we can use calc(color +
semi-transparent white) then it blends with alpha
blending?
TabAtkins: calc is for numerical things.
TabAtkins: We have cross-fade as existence proof that we use a new
function for specific things.
TabAtkins: We need color blending for convenience and so you can
???
Florian: device-cmyk
ChrisL: If you have calibrated device-cmyk.
Florian: That's no problem.
ChrisL: If you don't provide a fallback you get a bad color.
Florian: How does it work?
ChrisL: It means here are some numbers, don't mess with them at all.
Florian: If we composite and alpha-blend ....
ChrisL: If you use color() to do that, it looks better.
ChrisL: Inks are not transparent, can't overlay them.
ChrisL: Have a pattern of dots instead in a grid.
ChrisL: Overlaid in different angles.
ChrisL: If you have a pale yellow and then few dots of black.
ChrisL: That's what device-cmyk is for.
ChrisL: Don't want those black dots.
Florian: Why does output to PDF file have anything to do with the
screen?
TabAtkins: Don't have at a distance logic in MQ
Florian: If you're a headless device?
Florian: OS doesn't know what to do.
Florian: What does the MQ do?
ChrisL: It should say yes to everything, can print to pdf in any
profile.
leaverou: Can we get rid of device-cmyk somehow?
TabAtkins: It's implemented.
ChrisL: Black point compensation.
ChrisL: White is easy.
ChrisL: TVs can get much darker black.
TabAtkins: Can we not do something like white compensation?
ChrisL: No. the spec says why.
ChrisL: Same mutual axis.
ChrisL: It's not pegged at 0 it's pegged at some dark.
ChrisL: Certain amount at the bottom for deeper blacks.
ChrisL: Do need to cope with that.
ChrisL: Wording about rendering intents.
ChrisL: Black point compensation matches or not.
ChrisL: With or without black compensation.
ChrisL: In PS it will ask if you want black compensation.
TabAtkins: Which do we want?
cabanier: Turn it on.
TabAtkins: ok. Done?
cabanier: Color conversion engine can do it for you.
cabanier: Same thing happens with whites.
cabanier: White stays white.
RESOLVED: Do black point compensation when converting from profile
to another.
smfr: For print also?
ChrisL: Yeah.
ChrisL: Doesn't affect p3, does affect 2020.
TabAtkins: Can I reformat everything?
ChrisL: Sure.
Florian: The only thing we haven't agreed on is the working color
profile?
ChrisL: Right.
leaverou: device-cmyk
leaverou: Stylesheet was used for printing to ebook.
leaverou: Using something similar to device-cmyk.
leaverou: One problem is that you specify a device-cmyk color but
you want...
leaverou: it would be nice to specify which profile to use.
TabAtkins: Use the color() function and the cmyk profile?
leaverou: Want to use device-cmyk for print.
TabAtkins: What's wrong with just defining the cmyk profile in
color() instead of device-cmyk?
leaverou: I thought we decided to keep device-cmyk?
TabAtkins: Will fix by having a decent list of predefined
profiles, one of those can be device-cmyk.
TabAtkins: Falling back to something you have defined.
ChrisL: Seems backwards.
TabAtkins: If you have a correct profile for your output device...
dbaron: Is the assumption is that only print uses device-cmyk?
leaverou: Never want it for screen.
leaverou: Not just about PDF.
dbaron: Do you want a magic profile name for device-cmyk vs other.
leaverou: Want to specify colors once.
ChrisL: Want to see results from impl.
Florian: The printer has everything it needs to do it right.
TabAtkins: Use color(cmyk) will be good.
leaverou: ok that works.
TabAtkins: Get a good conversion instead of a naive.
RESOLVED: If you accurately describe the output device's color
profile in an @color-profile rule then a sane
implementation will not alter your colors so this is
sufficient as a replacement for device-cmyk in general
and provides a good RGB fallback automatically.
TabAtkins: We can deprecate device-cmyk.
*** Return to regular meeting minutes ***
Summary of breakout sessions
----------------------------
Scribe: fantasai
TabAtkins: Chris went over new features adding to color.
TabAtkins: General agreement on all of them.
TabAtkins: In particular lab() and clb() [mistyped].
TabAtkins: And new color() function.
TabAtkins: Refers to arbitrary color profile.
TabAtkins: Give it whatever parameters it expects.
TabAtkins: Paired with that is @color-profile rule, which lets you
refer to color profiles by URLs.
TabAtkins: Will have a handful of predefined ones.
TabAtkins: Since a lot of color profiles are quite small.
TabAtkins: Decided to be liberal in predefining common Mac and
Windows profiles.
TabAtkins: For less URLs.
TabAtkins: Wanted to make some changes around fallback.
TabAtkins: And adding fallback things to color profiles.
myles: What does UA do before downloading profile?
ChrisL: Uses a fallback color.
TabAtkins: We have 2 levels fallback.
TabAtkins: @color-profile can list fallback profiles.
TabAtkins: E.g. refer to AdobeSRGB, and fallback to regular sRGB.
TabAtkins: Can also fallback explicitly for specific colors.
Florian: If you did neither, it's invisible, becomes invisible.
TabAtkins: Also discussed color-mod function.
TabAtkins: Agreed to kill it in general, and then respec color
blending / tint / and shade functions.
TabAtkins: Because those are useful/simple that are highly
requested by authors.
fantasai: Did you talk about making a cut for Level 4 that's just
the really basic simple things?
TabAtkins: Did, plan to publish a new WD first to get an update,
then make a cut.
ChrisL: There was a lot of wording about rendering intent, decided
not to do, but since we had the wording, better to publish
with that wording and then remove it in the next
publication.
TabAtkins: At the end, casually decided to drop/punt APIs for
parsing/manimpulating colors.
TabAtkins: Going to explore in Houdini, if necessary.
TabAtkins: This isn't the right spec for it.
Florian: Also went through media queries, found spec as is to be
adequate.
TabAtkins: Wanted to make a clarification.
TabAtkins: but agreed on resolution.
Florian: Editorial.
TabAtkins: I believe that's it.
Florian: One thing we couldn't agree on.
TabAtkins: Wanted to define a working color space for compositing.
TabAtkins: But we couldn't agree on doing it right now because
it's very expensive to composite.
Florian: Could agree on the syntax for this, but not on the list
of color spaces to allow.
Florian: Some are expensive but good, others are cheap but wrong,
others are not well-understood by people at the table at
the moment.
TabAtkins: Hallway conversation with Elliott, opacity is misplaced
in this spec, better moved into either Filters or
Compositing spec.
ChrisL: Yes.
leaverou: Yes.
ChrisL: But also have alpha values.
<bradk> waaaa?
TabAtkins: Can just move it to V&U.
Everybody: What?
ChrisL: Putting in Compositing seems to make sense.
TabAtkins: <alpha> being <number> | <percentage> where number 0..1
[fantasai summarizes resolutions from scroll-snap breakout]
Grid
----
Scribes: gregwhitworth & tantek
TabAtkins: First issue is the repeating syntax.
TabAtkins: The grid auto rows only allow you to set one track worth.
TabAtkins: Once you have subgrid you want to repeat on more than
one track.
TabAtkins: So the repeat will take a track list.
TabAtkins: Auto is required, but maybe the repeat function should
be changed.
TabAtkins: Auto is actually required because you can't control the
implicit grid.
TabAtkins: Now that we have a reason to add back multi-track
repetition into the repeat() function but subgrid
brings that back.
fantasai: Not for auto fill.
fantasai: Subgrid is a compelling use-case (we didn't have one
before).
TabAtkins: It just repeats whole tracks, when you're dropping
tracks from fill you drop whole tracklists.
dholbert: These are two distinct changes.
fantasai: Yes.
astearns: Any objections?
Rossen: We'll bring issues when we get more implementation
experience, for now it seems reasonable.
<tantek> When you're dropping tracks from fill, you drop whole
repetitions etc.
astearns: Any objection to adding multitrack repetition to
accommodate subgrid use-cases?
Rossen: We'll bring issues with more implementation experience.
astreans: RESOLVED: add in multitrack repetition to accommodative
subgrid use-case
RESOLVED: Add allowing track list in repeat() and auto-rows
fantasai: We prefer to just drop named lines specified on the
subgrid because grid-template does not apply to
simplified subgrid.
fantasai: We are referring to dropping name lines specified on the
subgrid.
fantasai: Via grid-template-columns.
fantasai: Via the old subgrid you could do that.
fantasai: We're proposing to drop because it adds syntactic
complexity.
fantasai: Possibly can apply in the future in interesting ways.
fantasai: Since we're not tackling that now, let's just remove
that now.
TabAtkins: Any objections?
TabAtkins: Does anybody still want the ability to declare new
named lines on subgrids?
plinss: You can't create lines in a subgrid
astearns: Seems fine to drop.
RESOLVED: Drop named lines specified on the subgrid
fantasai: Can we publish a new WD?
RESOLVED: publish a new WD
Flexbox
-------
fantasai: One more thing, update flexbox CR
fantasai: we would like to update the CR with the issues
astearns: Any objections to publishing with edits?
fantasai: We're asking for people to setup the relative telecons
and do the whatever whatevers
fantasai: Resolution to take to CR once we generate a new draft,
and action chairs/staff to setup relevant telcons.
TabAtkins: I expect next week to finish bikeshed integration for
echidna
TabAtkins: and I expect to finish up the something akin
integration for pushbutton CR.
Rossen: Have resolution now?
fantasai: The disposition of comments is complete.
TabAtkins: Flexbox CR draft is done and ready.
astearns: Any objections to doing a new CR for flexbox?
<fantasai> https://drafts.csswg.org/css-flexbox-1/issues-cr-20160301
astearns: strategy, call for publications at the end of long days
dbaron: lol
RESOLVED Publish a new CR flexbox.
dbaron: And try not to break the 86 day record for slowness.
Inline
------
fantasai: CSS inline has had a few small changes from various F2Fs.
fantasai: Since we're publishing stuff maybe we should publish and
update to the inline spec.
fantasai: Proposed publishing new draft of CSS inline.
astearns: I'm sorry is this the fourth one more thing.
<tantek> +1
<dauwhe> +1
astearns: I'm happy to, any objections?
RESOLVED: Publish inline
gregwhitworth: Done for the day - Thank you Google for hosting
us!!!!!!
Received on Tuesday, 7 June 2016 18:26:38 UTC