- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 13 Mar 2016 08:37:47 -0400
- 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.
=========================================
Tables
------
- RESOLVED: Add gregwhitworth and franremy as editors of CSS
Tables and copy into CSSWG ED repo
- There was a desire to have headers and footers repeated; the
only disagreement was if it should be a 'should' or a 'must'
level.
- RESOLVED: 'contain' applies to table cells
Colors
------
- RGB color section outside of 0-1 is being addressed in a spec
written by Chris and therefore doesn't need to be explained in
the CSS3 Colors.
- There was a desire to create a new way to specify colors and
color profile and work will start to come up with language on
a proposed approach. Once written the proposal will go into
Colors 4.
- SteveZ will also get feedback from Adobe on how they expect
wide gamut colors to be handled.
Transforms
----------
- smfr gave a status update for the spec stating he's still looking
for implementor feedback on preserve-3d and some assistance from
someone who knows matrix math.
- RESOLVED: Republish Transforms
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2016
Scribe: fantasai
Tables
======
Introduction & ED
-----------------
[gregwhitworth walks to the podium, about to dive into the most
dangerous jungles of CSS: specifying Table Layout]
gregwhitworth: Hi!
gregwhitworth: We're going to talk about Tables!
gregwhitworth: One Spec to Rule Them All.
* gregwhitworth shows a photo of a wooden table, then of the One
Ring
gregwhitworth: I want to take all of these specs that define
"something" about tables, and marry them all
together.
gregwhitworth: Break this cycle of fixing bugs to fix some sites
that break other sites...
gregwhitworth: We do not want to add new features to Tables.
gregwhitworth: We don't care. We're not adding anything new.
gregwhitworth: Goal is Interop Interop Interop Interop
gregwhitworth: Also, to explain Reality.
[image of several copies of the word "interop" superposed but not
aligned.]
gregwhitworth: franremy did a great job in the opening, to tell
people that This Is Not Our Fault.
gregwhitworth: So many things just don't make sense about how
tables work.
gregwhitworth: But last year we were fixing tons of tables bugs.
[video meme of "That doesn't make sense"]
gregwhitworth: Developer reached out to us about a bug and said
"this doesn't make sense"
gregwhitworth: Tried to bring it to the working group, and working
group said... Ummm not defined.
gregwhitworth: Goal is to find all sections that are undefined.
[image of browser logos]
gregwhitworth: Also, find all interop issues.
gregwhitworth: The spec says "this should happen" and it doesn't.
gregwhitworth: Find all interop issues, and decide on something,
that is something someone is shipping. Unless
there's a really strong argument to not do that.
gregwhitworth: Goal is to by 2017, have our developers be able to
kick out 50% of those bugs.
gregwhitworth: Point to spec language saying "We're doing it right."
gregwhitworth: Allow other browser vendors to rev their table
layout to match the spec.
gregwhitworth: That's the goal of the spec.
<zcorpan> gregwhitworth++
<fantasai> gregwhitworth++
* bradk wonders how we can have interoperable tables without
accounting for row spans and col spans, which already
exist in HTML.
<tantek> "one table spec to rule them all"
gregwhitworth: On purpose, this is a ton of red.
gregwhitworth: A myriad of stuff from previous attempts at a spec.
gregwhitworth: From dbaron, Bert, Microsoft, CSS2.1
<gregwhitworth> http://gregwhitworth.github.io/css-table-3/
gregwhitworth: All I'm looking for there is a current CSS3 Table
spec in the repo.
gregwhitworth: This is a huge goal for us at Microsoft. Was asking
for ED.
fantasai: YES.
fantasai: It can't be the table spec to rule them all if
it doesn't include those.
gregwhitworth: Still a bit work to do before discussing specific
issues.
gregwhitworth: Just don't want to rathole on random discussions.
gregwhitworth: Here's a list of bugs we're tracking.
gregwhitworth: Browser vendors can look at them; our bug database
isn't public, so copied them out here.
gregwhitworth: Goal is to resolve 50% of them in 2016.
dbaron: One thing I was going to say is that I would be very happy
to see this in the WG repository.
dbaron: Even if you're not comfortable going to FPWD yet, should
be ED asap.
<SimonSapin> +1 for in wg repo
<tantek> +1 for put new draft in wg repo
dbaron: My intuition is that the least interop parts of tables
have to do with height calculations.
dbaron: I think width is substantially more interoperable than
height.
dbaron: Wasn't able to skim issues list when you went by,
dbaron: But if you're short of height issues, ask me for some.
gregwhitworth: We ran into lots of issues.
gregwhitworth: e.g. resolving px vs percentages in height
completely different than width.
gregwhitworth: There's gonna be a ton of issues.
dbaron: Height distribution in IE6 was saner, and a lot more
similar to width distribution.
dbaron: Don't say that very often :)
RESOLVED: Add gregwhitworth and franremy as editors of CSS Tables
and copy into CSSWG ED repo
<dauwhe> wonderful!
<tantek> amazing
zcorpan: I wanted to discuss something else...
zcorpan: I really like that there's this spec, and I'm happy to
contribute to it.
zcorpan: It also covers mapping from HTML to CSS, and that's
something that's already in the HTML spec.
zcorpan: I haven't checked it's the same.
gregwhitworth: IIRC there are holes.
gregwhitworth: We've only done this for 3-4 weeks.
gregwhitworth: I think okay with later on ripping stuff out, I
just truly would like to keep everything in one
place or now.
zcorpan: Should fix HTML once we know the right behavior.
zcorpan: Do you care about quirks mode here? Because I have some
quirks documented.
gregwhitworth: Not right now. Want to get standards mode
interoperable first.
gregwhitworth: I think that's a V2 state.
Florian: When Quirks mode are different from standards mode, yes.
Florian: But I think if everyone is different, it might be worth
checking out the quirks mode and aligning to that if it's
more sane, instead of aligning to one of the standards
behaviors.
gregwhitworth: That makes sense, but also have to consider that
since most pages are standards, that might break
things more since nobody does it.
astearns: You talked about interop without calling anyone evil or
naively characterizing their business model,
astearns: so thank you.
Table Header/Footer Repetition
------------------------------
<tantek> https://lists.w3.org/Archives/Public/www-style/2016Jan/0135.html
Florian: CSS2.1 is undefined about this.
Florian: When you fragment across fragmentainers, do you repeat
headers/footers or not?
Florian: Browsers disagree.
<dbaron> which browsers do what?
Florian: Think we should do that. And possibly have a switch for it.
Florian: Everyone who uses tables for print wants this.
Florian: If you're using tables for layout, wouldn't have
tables/footers anyway, so not a problem there.
Florian: I would like to go away from undefined and make it a MUST.
Florian: I'm okay if people say "only if we can turn it off", but
not necessary.
dbaron: Which browsers do what?
Florian: Firefox and Edge repeat the headers and footers repeat
across pages. Not on columns for some reason.
Florian: Webkit/Blink don't.
Florian: Printing implementations all do it.
dbaron: In Firefox's case, the "not on columns" bit is because the
code to do this does not support dynamic changes.
Florian: Would you consider it a bug to fix eventually?
dbaron: Do you consider heat death of the universe eventually?
Florian: Yes.
dbaron: Not going to a priority.
Florian: That's fine.
gregwhitworth: I think this is a good idea of what to file against
the spec.
gregwhitworth: For the column case, what are use case of splitting
tables for multiple columns?
gregwhitworth: What makes the most sense?
gregwhitworth: Say this is what we agree on, what's the use cases,
etc.
gregwhitworth: Use case may be so rare that not worth it.
Florian: Use case is pretty simple.
Florian: Think of a scientific document. LaTex 2-columns, includes
data table.
Florian: Table is broken across pages or column as necessary.
gregwhitworth: What happens if you have very small viewport?
Florian: I think we agree we need to have error-handling code for
not enough room.
Florian: I would suggest drop footer if not enough room, if still
not enough drop header.
Florian: I can take it back to the list if you want.
gregwhitworth: I think we should spec printing, discuss for other
thing.
Florian: I'm not sure I want to distinguish here.
Florian: Don't want to distinguish between print/non-print UAs.
<dbaron> We actually don't split tables at all when they're inside
of multicols when printing.
<dbaron> (from https://bugzilla.mozilla.org/show_bug.cgi?id=678447 )
fantasai: I think the spec should recommend repeating. If we can't
say MUST due to implementations not being able to
implement soon, then that's fine, we call it "SHOULD"
and not "MUST".
gregwhitworth: Prefer to going with MUSTs than SHOULDs in the spec.
* franremy agrees with gregwhitworth here. SHOULDs are a pain.
<zcorpan> gregwhitworth re forms in tables, it's not rendered in
webkit/chrome if the form is foster-parented. so seems
like something that can be fixed in webkit/chrome rather
than spec, unless you found sites being broken in gecko.
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3850
Applying 'contain' property to tables
-------------------------------------
Florian: There was a side-discussion wrt applying 'contain' to
internal table elements.
Florian: Not sure I a see a good reason for not applying to table
cells. For table rows, I care less.
Florian: But I think it makes perfect sense to apply to table cells.
Florian: I wanted to get a sense of consensus of implementers,
when you implement 'contain' can you also apply to table
cells?
dbaron: Table cells aren't the only type I'm worried about. E.g.
what does it mean for 'display: inline'?
dbaron: I think 'contain' needs to be doing blockification.
dbaron: Most display types don't work with 'contain'
ojan: I thought it forces a block?
leviw: It's not in the spec.
leviw: I agree it doesn't make sense in the inline flow case.
leviw: I think it should just say...
dbaron: I see this in the spec
dbaron: It's well-hidden.
dbaron: "Layout containment forces a formatting context ....."
[several people peer at dbaron's screen]
dbaron: It's not actually defined. "The element MUST be, no
definition of making it"
ojan: I'm sure that was the intention, need to give feedback to
TabAtkins.
franremy: Table cells are very similar to block.
franremy: No reason to believe we can't use 'contain' on a table
cell.
Florian: ...
RESOLVED: 'contain' applies to table cells
Rossen: Okay, lunch is scheduled for ~1pm
Colors
======
RGB color selection values outside of 0-1
-----------------------------------------
<dino> https://lists.w3.org/Archives/Public/www-style/2016Jan/0301.html
dino: Had a conversation in Sapporo,
dino: Sent a follow-up mail.
dino: First suggestion is, CSS3 Color spec already says RGB color
section that it allows values outside of 0-1.
dino: If you're on a device that supports that gamut, you should
show the colors, otherwise clip.
dino: Nobody has implemented that yet.
dino: There's a few things to discuss.
dino: Doesn't say what those colors mean.
dino: sRGB doesn't say what to do.
dino: There's a spec from Microsoft scRGB, which specifies what to
do outside of 0-1.
dino: Maybe we should update the spec to explicitly link to that.
<astearns> https://en.wikipedia.org/wiki/ScRGB
dino: Also, we're not so sure what tools would allow devs to
specify this.
dino: Maybe a question for Adobe, what would you do in Photoshop
to pick a color on your fancy monitor that's outside sRGB,
dino: And have that convert to e.g. -10%.
SteveZ: I'm not quite sure that I'm prepared to answer that
question directly.
SteveZ: But my memory is Photoshop uses its own color space most
of the time.
SteveZ: It's an Adobe color space.
dino: Say you have an image with a very bright red, outside sRGB,
dino: Tagged with color profile,
dino: And now you want to have your web page background match.
dino: You only have the ability at the moment to specify that
using the background: rgb() syntax.
dino: How is a dev going to figure out what values to put in rgb()
syntax?
SteveZ: I can ask the ICC guys.
dino: This would be useful feedback.
ACTION SteveZ: ask ICC guys how authors can choose colors outside
sRGB
dino: We're trying to specify how to read the value and spec on
screen, but doesn't help anyone if they can't actually
figure out what numbers to use.
Florian: Chris is working on spec to be able to specify colors in
different color spaces.
Florian: Once we have that, do we need this hack around rgb()?
Florian: Couldn't we just use the proper color syntax with that?
Florian: Or do we need this fix?
dino: Answer might be yes, don't need to do this.
dino: But then we should go back to clamp the values outside 0-1.
smfr: So, I think we're trying to solicit feedback on Adobe on
what the authoring story is.
smfr: How can you author things to work correctly in the deep
color world?
smfr: And want to make sure what Chris is writing works with that
too.
smfr: Let's say you have a very deep red, and want to match color
in CSS,
smfr: If they both end up on a regular display,
smfr: Need to make sure the colors still match.
Florian: Chris is dealing with that.
New way to specify colors and color profile
-------------------------------------------
dino: 2nd thing we sort of agreed on;
dino: a new way to specify colors, along with color profile.
dino: I figured a function named color() makes a lot of sense...
dino: How do you specify which color profile ?
dino: We had an @color-profile, but I was going to suggest some
keywords for common profiles
Florian: I believe what we discussed last time was a function
which starts with the name of the color space and an
arbitrary set of parameters, not even necessarily numbers,
Florian: some predefined, e.g. sRGB.
Florian: And others name and link to ICC color profile.
Florian: Not necessarily numbers, because might want to use spot
colors, e.g. Pantone.
Florian: I'm not sure it's happened so far.
<bradk> PMS = Pantone Matching System
<bradk> Pantone Matching System is trademarked or something
dino: We might write up a proposal.
dino: I suggested that possibly an alternative to this is that we
come up with another function that is defined to be colors
space bt2020.
dino: Much bigger than sRGB. many monitors, HDTV, are aiming at
that.
dino: Hardware sometimes say it supports, but doesn't really.
dino: Might say rgb2020...
Florian: This isn't a quick solution, because the problem isn't
the syntax, it's color conversion.
Florian: Switching color spaces, syntax is trivial once you have
the conversion math.
Florian: But need to have basic model in place.
zcorpan: Whatever we come up with, should be consistent with what
we do in HTML for <canvas>.
zcorpan: Some idea floating around, about being able to point to
an actual image and use the image's profile,
zcorpan: That seems could be useful.
dino: The basic reason you'd want to do that is authors don't know
how to specify a profile, but do have plenty of images.
zcorpan: So can pick a point on the image, and this is the color I
want to match.
Florian: I think that's something we can do in the syntax we were
discussing. Could point to an ICC profile, but could also
point to an image and work within that image.
dino: How do authors detect whether they're in a system that
supports deeper colors?
dino: Could use an MQ.
dino: Does the output device have enough range to support all the
colors in this color?
dino: Not necessarily useful thing to ask.
dino: Could ask, is this the kind of like we have today, or
better, or super-awesome?
fantasai: color: normal | good | awesome ? :)
dino: or if I support a color in this syntax, will it be clamped?
<zcorpan> @supports (color: color('bt2020', ...)) { ... } ?
fantasai: @supports is for do you support the feature in the
browser.
fantasai: Media Queries is about querying the capabilities of the
output device.
Florian: For qualitative MQ...
Florian: The difference between regular and fancy I can see, but
in terms of actual authoring usage, what do you
differently in terms of styling if you have a more-
awesomer screen?
smfr: You might want to support different image assets.
Florian: Even though you don't know how much "better" it is?
smfr: We'd specify better as ?? and even better as bt2020
smfr: ... which roughly equates to 10-bit color and 12-bit color.
Florian: Bit depth of a color is not directly linked to the gamut
of it, but broader color spaces tend to be associated
with higher bits, because otherwise don't have enough
precision.
dino: Awesome vs awesomer... most devices in the consumer market
say that they're awesomer, but they're only actually awesome.
Florian: Most of them barely reach normal.
Florian: Most screens don't cover sRGB color space, never mind
broader one.
zcorpan: I wanted to discuss a bit about feature discussion.
zcorpan: If the syntax we come up with this is a color function,
zcorpan: And we allow profile,
zcorpan: And we say color profiles that are not supported are
invalid,
zcorpan: then @supports is the right solution.
Florian: Old-fashioned @supports wouldn't work here.
Florian: The behavior we expect from a browser isn't to drop the
declarations if not support the profile, but to convert
the colors.
Florian: You support all colors, you just might not display them
equally nightly
smfr: @supports is explicitly about asking about what features the
engine supports. Swapping monitors doesn't change the
results of @supports.
smfr: This is a question for media queries.
Florian: Goal of discussion?
dino: Think there's reasonable consensus. Might make direct
suggestions rather than waiting for stuff to happen.
Florian: That's the only sane want to do this.
smfr: Would like to get an action on authoring tool vendors to
give us feedback.
SteveZ: I have no idea what the feedback will do, but certainly
willing to take the action to try.
ACTION: SteveZ ask authoring tool people how authors can specify
colors outside sRGB
trackbot Created ACTION-747
dino: Feedback on how authoring tool vendors expect ppl to work
with wide gamut colors. how do they choose colors?
astearns: How can they choose colors in a way that's compatible
with how the tool emits colors.
smfr: It's not just choosing colors in the UI, it's managing deep
color assets through the whole content management chain.
smfr: Final comment to make...
smfr: I would love to see Firefox and Chrome start treating CSS
colors as sRGB on wide gamut displays
smfr: Specifically on new images,
smfr: not getting color matched.
smfr: Colors get too bright, gives you a headache.
smfr: Would like to see other UAs do color matching, hopefully
that will also encourage them to give feedback
Rossen: Is this going into Color 4?
Florian: I think that was the plan.
Rossen: That takes us to the end of the morning agenda.
Transforms
----------
smfr: Didn't have time to get all issues together.
smfr: No change to status since last time we discussed.
smfr: I'm waiting mainly on feedback from implementers, especially
with regards to preserve-3d behavior.
smfr: Spec was revised 18 months ago with new description of
preserve-3d behavior and 3D context behavior.
smfr: Got some feedback from roc; he liked the description but
some issues with regard to intersection.
smfr: Still have very poor interoperability among implementations
with regard to preserve-3d behavior. Particularly want
feedback.
smfr: Fairly hard problems with getting a solid description of
this,
smfr: Particularly with transform-style: flat,
smfr: and creating a stacking context.
smfr: Other side of it is, being wary of the compat risk of
changing behavior.
smfr: So if we do change the spec, would UAs be willing to change
behavior?
smfr: Compat risks are possibly high for WebKit, though may be
willing to change behavior for non-prefixed (vs. prefixed).
smfr: So might get a behavior split there.
smfr: That's the basic status.
smfr: I also have a call for help with someone who knows more
matrix math,
smfr: To help define things like backface-visibility.
smfr: If anyone has people who know transform math better, would
be helpful.
smfr: Need also help editing.
dbaron: I'm also very concerned about preserve-3d, especially
interoperability for 3d in general.
dbaron: One of my concerns has been that we hit an interop issue,
and it's hard to look at the spec and determine who's
right according to the spec- according to what's there.
dbaron: Which is worrying.
dbaron: It's been awhile since I looked at any of these.
dbaron: I think we're interested in trying to improve interop,
dbaron: Hard to commit to doing that at a particular time.
dbaron: Probably for the next 2-3 months we do not want to make
substantive changes,
dbaron: Because we made an architectural change, and we need to
fix all the regressions first.
dbaron: I think after that, would like to prioritize,
dbaron: Don't have any particular concrete suggestions.
fantasai: Is the most recent WD is from 2013?
smfr: That's out of date. I think krit has requested public WD...
fantasai: Do we want to republish?
RESOLVED: Republish Transforms
Vollick: We haven't implemented also because of an overhaul, will
have to get back to you.
smfr: Edge?
Rossen: Not a current priority for us.
Rossen: Implementation we did a few months ago...
Rossen: Implementing most interoperable version, which is older
version.
Rossen: I can get you an update.
[lunch]
Received on Sunday, 13 March 2016 12:38:44 UTC