- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 15 Nov 2016 21:27:42 -0500
- 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 Scroll Snap
---------------
- RESOLVED: Defer the event model to the next level
Media Queries
-------------
- RESOLVED: Do not add a less-than-srgb Media Query
- RESOLVED: The new value (the the script media query) will be
punted to the next level.
- RESOLVED: Publish that (Media Queries 4) as a working draft
Grid
----
- RESOLVED: block-axis baselines are not supported (confirmed!)
- RESOLVED: percentage gaps and percentage tracks use same
resolution method
- RESOLVED: Percentages in intrinsically sized grids tracks and
gaps will either get back computed or not.
- RESOLVED: Grid to CR
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2016#agenda
Scribe: frremy
CSS Scroll Snap
===============
Scroll padding
--------------
fantasai: We have one open issue, which is scroll padding.
[Florian and fantasai are deciding who to present]
Rossen: Matt wanted to be able to join for this issue
<fantasai> https://github.com/w3c/csswg-drafts/issues/156
Rossen: Let's change the order of topics.
Event Model
-----------
fantasai: Another issue is the event model.
fantasai: The proposal is to defer this to the next level.
Rossen: Any objection?
TabAtkins: I would rather have scroll snap as soon as possible.
Rossen: Since there are no objection, let's call this resolved.
RESOLVED: Defer the event model to the next level
Florian: If you try to snap to something beyond scrolling reach,
what happens?
fantasai: The snap position is changed so that it becomes in range.
Florian: My understanding is that is says precisely how you snap
Florian: but now whether you should do it.
Florian: Another part seems to indicate you don't
Florian: because the "corridor" is not defined.
fantasai: Since you *shift* them inside range, they are.
Florian: ok, this didn't used to be written this way when I filed
the issue.
Florian: I am convinced by the explanation now.
Florian: I'll review again and will return if I find anything
else, but its ok for now.
Media Queries
=============
Florian: 4 issues
Issue #3 - add a value specifically for the "less than sRGB" case?
------------------------------------------------------------------
<Florian> https://drafts.csswg.org/mediaqueries/#issue-d9e3b586
Florian: Issue 3 needs to be discussed.
Rossen: The color one?
Florian: Yes.
Florian: Should we have a "shitty" color one, when you support
colors, but poorly.
dbaron: We already have grayscale btw.
Chris: What would you do in that case?
dbaron: There is one for srgb.
ChrisL: Still not sure what the author could do with it.
Florian: I am not arguing in favor, just trying to make sure we
considered.
ChrisL: We want to go up, not down.
LeaVerou: Devices with small gamuts typically display colors as
less saturated.
LeaVerou: So you might want to adapt.
dbaron: There are more than just "non-srgb" and "close-to-srgb"
LeaVerou: How about a percentage of coverage?
Florian: Any measure won't be expressive enough.
LeaVerou: It's not perfect but looks sufficient.
Florian: How about one point "less srgb but still better than
usual"?
fantasai: We should have a note.
fantasai: explaining what matches what
<fantasai> explaining what it means to match not sRGB
<fantasai> which is implied by the spec, but not clear to readers
dean: The issue is also browsers that just do not support the
media query
dean: if you try to detect "not-srgb".
Florian: It is a general issue.
dean: But now makes it worse.
Rossen: Proposed resolution is then to resolve as won't fix.
Rossen: No objection?
RESOLVED: Do not add a less-than-srgb Media Query
Script Media Query
------------------
Florian: Other issue: script mq
Florian: How about engines that run scripts, but only until some
point (like printed).
Florian: If the MQ doesn't tell you that it is supported, the MQ
isn't very useful to depend on.
Florian: Maybe a value would be great.
Florian: But defining the threshold is tricky
Florian: but if we define a threshold might force user agents to
lie about it
Florian: so we should probably keep it fuzzy.
Florian: We discussed but we didn't resolve on that last time
tantek: Any pointer to the old discussion?
Florian: Nope, sorry
< > https://drafts.csswg.org/mediaqueries/#scripting
Florian: but this summary is about as good as it got
<Florian> https://drafts.csswg.org/mediaqueries/#issue-51d591c9
Rossen: Your preference?
Florian: Not changing the spec, keep fuzzy.
Rossen: fantasai, since it is your issue, what is your call?
fantasai: I am fine with a fuzzy boundary, but I want at least one
certainty value people can trust.
Florian: A "onload" threshold could be an issue if there is a
timeout.
Florian: So I don't think it would help anyone.
Rossen: But would it solve the issue?
fantasai: I don't know, you guys know.
fantasai: But authors want at least some way of knowing that.
fantasai: if we define a baseline, at least authors can depend on
that baseline.
fantasai: Otherwise, people will rely on undocumented heuristics
and we won't get interop.
fantasai: I know almost no JS, but if I write a script, I want to
know if it will be guaranteed to run, interoperably.
tantek: Please capture this in github.
tankek: Second question, did anyone prototype this?
Florian: Not any implementation
Florian: that I know of.
tantek: Then lets assume none.
tantek: Then let's mark as at-risk.
Florian: Fine by me.
<tantek> https://drafts.csswg.org/mediaqueries/#scripting
<tantek> the summary artificially constrains what the feature
implies
tantek: (pasting what he just read)
tantek: That description constrains the use case.
tantek: It could be used to do more things.
tantek: So it's misleading.
Florian: I am fine doing this editorial change.
<bkardell> Is it actually useful to detect the opera mini case?
Because it is an arbitrary cutoff
<gsnedders> bkardell, Yes. And it's horribly awkward. See all
usage of :root.no-js etc.
dbaron: If you want to figure it out, you need use cases where css
needs to be different based on javascript running
dbaron: why not just have the script do something.
dbaron: Like removing classes that will trigger the behavior
dbaron: assume it won't run
dbaron: then cancel the effect.
<dino> 100% agree with dbaron
TabAtkins: It's cheaper on MQ.
TabAtkins: So performance might be better.
tantek: What is this nojs class nonsense, you can just flip the
stylesheet to enabled.
LeaVerou: Reality is, all big websites use a nojs class that they
remove via JS. They do not toggle stylesheets, because
this is easier for maintenance.
TabAtkins: Friendlier to bundling.
<dbaron> that said, I think the main use case is really just "is
script enabled"?
* jcraig wonders if you couldn't use a custom -scripts-loaded
media feature
Florian: Can we just agree on a "something will run, at least"?
dino: Let's set the print baseline.
dino: When the rendering finalizes, scripts stop running.
tantek: ok, then lets call that value "onload"
gsnedders: Has Opera said if they're going to implement this
middle value? has anyone?
simonp: Opera Mini is still using Presto and we're not going to
implement any new features there.
gsnedders: So is it theoretical only?
LeaVerou: Google crawler does run some scripts.
eliott: Google crawlers won't report that.
eliott: We just act like if we were really loading the page, right?
Florian: Then we can make the entire MQ as at-risk
tantek: Let's punt the new value to the next level.
Rossen: Would you oppose that?
Florian: I don't oppose either way.
tantek: Lack of prototype is a strong signal to punt it.
Rossen: Any objection?
RESOLVED: The new value will be punted to the next level
?: what to do with intermediate value?
dbaron: I think it should probably match what people do with nojs
classes, which means those implementations should return
true
Rossen: What about the entire MQ?
Florian: We should keep, as at-risk.
Florian: Print is a valid use case.
Rossen: Proposal is to mark it as risk, then. Objections?
RESOLVED: Keep the script-detecting mq, but mark as at-risk in
current level
Florian: We now need to make a disposition of comments
Florian: but we went through all the known open issues.
Rossen: Okay, anything else on the topic?
Florian: no, I'll ask for CR when we are done with these
(various +1)
tantek: Ask for a review after you made those changes, please
Florian: OK
RESOLVED: publish that as a working draft
Grid
====
Rossen: There was a grid issue to be discussed?
<fantasai> https://drafts.csswg.org/css-grid/issues-wd-20160519
Baselines (Issue 14)
--------------------
fantasai: First one is the baseline issue.
fantasai: We decided to not to have block-axis baselines
fantasai: but original poster isn't very happy.
fantasai: proposal is: given lack of review, we should drop the
feature for now, but maybe consider for later addition.
fantasai: For a while, it is not expected you can make it work
anywhere.
Rossen: Anyone objecting to keep the current resolution not to
work on block baselines?
jet: I am just wanting to check that it is what we are going to
ship.
fantasai: I can also make it undefined.
fantasai: The point is not to make it prevent the spec to go to CR
jet: Wait wait wait.
jet: Let's see if we match first.
fantasai: Can I get a response today?
jet: I hope so.
<jet> fantasai: bug 1151204 btw
tantek: Would it be possible we match others?
Rossen: Not us, we don't have vertical baselines at all
dbaron: Why would an author want that?
dbaron: They can make the whole grid vertical.
fantasai: Mixed mode.
dbaron: Seems like the case you describe should be described in
the other way, and you don't have the problem.
fantasai: Yeah, it's just a convenience in that case.
<fantasai> Discussion was about block-axis baseline alignment, for
example by having a column of 5 author bios which are
horizontal-tb grids with vertically-written author
names in the first column of each bio item
<fantasai> and then you want to align along the block axis the
vertical bio names within the column of the parent grid
<fantasai> dbaron was saying that you could just make the items
vertical and make the rest of the content inside them
horizontal
<fantasai> and that would solve the problem
<fantasai> and agreed that we should not have block-axis baselines
as a feature
<dbaron> but my point was that if you have a grid item where the
thing you want to align is vertical, then structurally
that grid item is vertical, with some horizontal stuff
inside -- and then you don't need block-axis baselines
Rossen: Just a reminder, we want to keep an existing resolution.
Rossen: How about we resolve again, and you reopen if you need?
jet: Looks fine to me.
Rossen: Anyone else want to object?
RESOLVED: block-axis baselines are not supported (confirmed!)
Rossen: next issue?
Percentage margins and intrinsic sizes
--------------------------------------
Scribe: gregwhitworth
fantasai: The only other issue is % gaps.
fantasai: We resolved to treat them as empty tracks.
fantasai: mats disagrees as he thinks they should back resolve the
percentages.
fantasai: I think that Ilgalia has implemented intrinsic percent
to auto and back computing other ones.
Rossen: Wait, they're not symmetric.
fantasai: No, I don't think so.
fantasai: This deals with how to deal with % in CSS in general.
fantasai: Let's say you have a float and a block inside that with
%s and it will overflow.
fantasai: We can't change that because of back compat.
<fantasai> https://github.com/w3c/csswg-drafts/issues/347
dbaron: We do back tracking for margin/paddings when inside of a
shrink wrapped container.
fantasai: If we go with the order of importance then we show go
with what Gecko does.
fantasai: That's what author's want.
fantasai: Where we don't have a back compat issue do we want to
fix them or fallback to auto.
Rossen: We've discussed this in the past.
Rossen: Our experience in the area is that this is very fragile
especially when %s go over 100
Rossen: so trying to backcompute the margins becomes really crazy.
Florian: What does it mean if it is over 100%
dbaron: I think the answer there is to only deal with it in in
maxcontent widths and not mincontent widths
dbaron: that way you'll be ok.
Rossen: At the very least min and max are supposed to be treated
differently.
fantasai: I think I have a bunch of related questions, the key one
here is gaps.
fantasai: We figured it'd be nice if the gaps are handled similar
to tracks, and that's what Mats has been arguing for
fantasai: that's one option.
fantasai: The other option is to make them compute the same and
fallback to auto.
fantasai: Make them compute the same but have them both back
compute the %s.
Rossen: Our opinion is #2.
Rossen: Behave consistently and fallback to auto
Rossen: Consistency over inconsistency
Rossen: and implementation simplicity over complex % back tracking.
Florian: As in it's hard for browsers to get them right?
Rossen: Yes, especially when you nest them.
dbaron: I'm not sure what nesting them has to do with it.
dbaron: You go level by level resolving the % against that of the
intrinsic width.
fantasai: I don't have an opinion on this.
fantasai: It would be good to hear from the Blink folks.
ojan: Hi.
dbaron: It would help if someone explained the issue.
dbaron: [draws a diagram on the board]
<div>
<img src="100x100.png" style="margin-left: 20%">
</div>
dbaron: We make the intrinsic size 125px
dbaron: and the whole thing fits.
dbaron: Gecko does this for margins and padding in this case, and
other impls don't.
dbaron: What we're talking about is doing this sort of thing for
grid stuff.
dbaron: So the alternative here, is if you ignore the % you make
the intrinsic width 100px
dbaron: you end up with a margin that is 25px and it overflows by
25px.
dbaron: If you ignore the percentage, you make the div 100px, and
the margin is 20px, and it overflows.
Florian: Which doesn't sound like what an author would want.
fantasai: I think there are actually two things happening here
fantasai: One of them is: if you have a child box of an
intrinsically sized element for grid we would have a
track that is in a shrink wrapped grid container.
fantasai: We can say that % depends on an indefinite size and
treat it as auto and we won't have the overflow problem.
dbaron: I don't think that's quite true.
dbaron: One of the things this gets you, if you have the image
inside of the grid track and says 20% and the image is
100px and the track needs to be 20% of the parent then
this will cause overflow.
dbaron: Tables do this, nothing overflows.
TabAtkins: Let's keep that in tables.
dbaron: You might have overflow but it depends on the sizing the
of the tracks.
dbaron: If you end up with a 300px grid and then you say, this
piece is 20%.
Florian: That's not what fantasai is saying, it's ignore.
dbaron: For everything or just intrinsic sized items.
fantasai: For everything.
dbaron: That's ok too.
fantasai: I don't want overflow.
Rossen: I want to timebox this discussion.
Rossen: There are two things we need to decide, do we want
consistency with gaps and tracks (in regards to resolving
%s)
dbaron: So treating them as a 0 even though you asked for a %
there will be nothing there.
ojan: That seems fine to me.
Rossen: What does?
ojan: If you put an % sized gap on an intrinsic sized track that
seems fine to 0 them out.
fantasai: So Mats Palmgren said we should back compute on gaps,
not tracks because it's more complex.
fantasai: So we end up with 3 options.
Rossen: So in other words, two of them would be consistent and one
of them would not.
Rossen: Would any one object to keeping them consistent?
Rossen: Let's call it resolved.
RESOLVED: percentage gaps and percentage tracks use same
resolution method
Rossen: Now on to the other part, if they're consistent are we
back computing %s or not?
Rossen: Does anyone object to not back computing %s on tracks?
dbaron: I would like to hear actual author feedback.
Rossen: Are there any objections?
jensimmons: I don't know what you're discussing?
gsnedders: I think asking for author point of view makes a bit of
sense, but, I think back track has to be there or it
does not make sense.
dbaron: What are the use cases for intrinsically sized grids.
dbaron: I feel like it's mainly used for top down not bottom up.
jensimmons: It's pretty big deal honestly.
jensimmons: People will expect the math to add up.
<rego> a simple example of a percentage gap and how it actually
works in both FF and Blink/WK implementations:
https://github.com/w3c/csswg-drafts/issues/345#issuecomment-240333816
<rego> tracks work exactly the same right now, so using: grid:
100px 10% 100px / 200px 10% 200px; behaves consistently
fantasai: Let's say you have a grid, it's floated, it's
intrinsically sized.
astearns: What if we wait to get more author feedback rather than
just getting feedback from the author in the room?
ojan: I would like to figure out if we can do what Gecko does.
dbaron: The way table column width assignment is very similar to
this.
ojan: There are two things we can do offline: 1 get author
feedback and 2 get desire to implement this from UAs.
fantasai: We will keep the resolution and then spec out both and
fix this in three months in Seattle.
fantasai: Mark it undefined so we can go to CR
<gsnedders> I'll also note after what was minuted for what I said,
Rossen asked if I'd object, and I said "yes" (somewhat
apprehensively)
RESOLVED: Percentages in intrinsically sized grids tracks and gaps
will either get back computed or not.
Publication
-----------
fantasai: We would like a transition to CR.
RESOLVED: Grid to CR
<ChrisL> (I was just asking fantasai about DoC etc and wide review)
Received on Wednesday, 16 November 2016 02:28:46 UTC