- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 Feb 2016 19:50:03 -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.
=========================================
A value for image-rendering to request high-quality rendering
-------------------------------------------------------------
- An as-yet unnamed property will be added to allow authors to
indicate that higher quality rendering is desired. This will
allow implementations of 'auto' more freedom in reducing
quality to improve performance.
Values and Units
----------------
- The prose defining directional <<angle>>s as bearings will
become a note stating that it is a CSS convention.
- Review was requested on calc() serialization spec prose soon by
those interested.
- toggle() will move to level 4 of values and units.
Gradient rendering and image-rendering property
-----------------------------------------------
- The group didn't see a need to have image-rendering apply to
gradients. Those with thoughts on this topic will also respond
on the list.
Layout containment and overflow
-------------------------------
- Generally the group was inclined to say that we allow visible
overflow, but if it overflows the parent scroller you can't
see it.
- TabAtkins will discuss this decision with the implementor
working on it to see if it fits with implementation experience.
-webkit-user-select
-------------------
- RESOLVED: Spec some set of -webkit-user-select values.
- Rossen and/or gregwhitworth will help Florian decide what that
set of values should be.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Feb/0161.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Dael Jackson
Chris Lilley
Peter Linss
Myles Maxfield
Thierry Michel
Edward O'Connor
Simon Pieters
Anton Prowse
Matt Rakow
Florian Rivoal
Alan Stearns
Lea Verou
Ian Vollick
Greg Whitworth
Regrets:
Tantek Çelik
Daniel Glazman
Michael Miller
Scribe: dael
A value for image-rendering to request high-quality rendering
=============================================================
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0016.html
smfr: This started when I implemented image rendering in webkit.
smfr: We have a behavior where if an image is painted often it
goes to a lower quality. There's no way for the author to
opt out for now. There used to be a value for optimizing
quality, but it's being deprecated. There's no replacement
to indicate 'do better than auto.'
smfr: Amelia posted a follow-up to my message. She suggested
smooth but I don't like it because it's not necessarily
smooth, it's look good. I'm open to other suggestions.
<TabAtkins> The original reason I left this out was because we
concluded that browsers would always opt for the
highest-quality rendering they could get anyway, and
authors have a good chance of trying it on their own
powerful laptop and going "performs great, ship it",
leaving low-powered devices getting pretty pictures
but terrible perf.
<TabAtkins> So I think it's a quality-of-implementation thing. If
images often get booted into low-quality unexpectedly,
fix that. Detect things better and use higher-quality
more often.
astearns: Does this new value mean don't do anything, or is it to
improve?
smfr: It's not do special processing, it's use...another thing I
should say this applied when the image is being scaled
usually so there's a scaling factor...it's telling the UA to
use best quality algorithm.
hober: Besides the aesthetics of the old name, is there a reason
why not to un-deprecate?
astearns: TabAtkins said on IRC why he remembers dropping.
astearns: So do we want to have something in CSS that allows
Safari to avoid this image optimization when that
optimization strategy isn't optimized?
Rossen: How is this intersecting with source and picture and all
the other abilities authors have to optimize quality and
payload? Isn't that what we should strive for devs to use
rather than UA optimize this away?
smfr: It's different. Those allow the author to supply assets.
This is once you have the asset and scale, what algorithm to
use.
Rossen: Gotcha.
Rossen: It's when scaling is applied...okay.
Rossen: We used to have something similar.
<astearns> best-scaling?
Florian: For TabAtkins's IRC, even if there was high quality the
UA could use it as a hint. So it could still drop if
there was a performance problem. Because there is a risk
they could just set it everywhere.
MaRakow: smfr, were you saying don't do the proposed smooth but a
different behavior?
smfr: I'm okay with something like smooth, I just don't like the
word.
Rossen: We're converging to we need to revive the old property or
have something else.
TabAtkins: What was the objection to what I said? That this is
quality of implementation issue?
Florian: I pointed out that if we get into a place where authors
use it too much, the UA can just use it as a hint but can
eventually do whatever it wants.
TabAtkins: So if you do that the value is the same as auto but if
you're in resource constraining prioritize others over
this.
TabAtkins: That doesn't seem quite what is being asked for.
Florian: It doesn't seem quite. It's a middle ground.
TabAtkins: smfr what is the opinion on detecting better?
smfr: We would love to improve everywhere and get rid of low
quality scaling. But I'm not sure...on low power we may have
performance issues. There is value in the authors saying
something is important enough.
TabAtkins: I see value in 'my headline is the prettiest,
prioritize if you can'. Something like that seems
valuable.
smfr: We don't have a notion of ranking images. We just make a
choice when we get to an image.
TabAtkins: If we were to add a high quality value, what happens on
a low quality device that doesn't have power?
smfr: They could try high quality and the user gets bad
performance or they fallback to auto. I think it's okay for
this to be a hint that can be ignored.
TabAtkins: I think that's the same as what I said on priority. I'm
fine if it's explicitly said that UA can ignore and use
low-quality when needed.
Rossen: I'm not sure this is giving much. If we're saying please
do it and there's still room for UA to ignore then this
defeats the purpose. I'd rather go back to your first
suggestion TabAtkins and let UAs do a better job. Don't
put this in the power of users because they'll just use it
everywhere. So I'm not in favor of having a property that
sometimes works.
TabAtkins: That's why I was thinking prioritization. So spend your
limited resources on this image over everything. So
prioritizing every image is the same as doing none. But
if you're judicious it could be useful. but if you're
not implementing prioritization, there's no value.
MaRakow: I think it's somewhat interesting, but I think it would
be to allow auto to be lower quality. The safe default is
high quality scaling. I think being able to have a
differentiator would let us improve auto, not have a new
higher quality.
TabAtkins: So by default you can degrade more heavily because
authors have an escape.
MaRakow: We used to have MS interpolation and didn't see
widespread use. So I think it's more interesting to let
us slice the auto rather than a new higher level.
TabAtkins: I see that. I see why slicing the semantics of auto
more could be worthwhile. Okay.
TabAtkins: I'm fine with accepting. Do we want to take naming to
mailing list?
fantasai: Why don't we reuse SVG names?
TabAtkins: We can. That's certainly a good suggestion.
fantasai: We should definitely accept those names.
ChrisL: If it turns out we need others, though...we should look at
those, but we may decide that they don't do enough.
TabAtkins: Right now optimize is mapped to auto, we map it to the
new one. Is the SVG good enough that we can use it? We
can move to ML.
smfr: The crisp edges value here...I suspect no UA implements this
and it seems to conjure pixels from thin air
ChrisL: I think Batik did it. Adobe for a while did but people
abused it.
TabAtkins: Mozilla does.
TabAtkins: I don't know what the implementation does, but it has
an effect other than auto.
MaRakow: I think the image in the spec is from a wikipedia page.
TabAtkins: Yeah, it's from wikipedia. pixel art scaling thing.
<smfr> looks like crisp-edges is
https://en.wikipedia.org/wiki/Image_scaling#hqnx_family
Values and Units
================
New prose defining directional <<angle>>s as bearings
-----------------------------------------------------
<astearns> https://drafts.csswg.org/css-values-3/issues-cr-2015#issue-1
<astearns> https://hg.csswg.org/drafts/rev/98da29d1dabb
<fantasai> https://drafts.csswg.org/css-values-3/#angles
fantasai: TabAtkins added prose stating that angles when used as a
direction must be treated as bearing angles. I wanted to
check with the group that this is appropriate.
fantasai: Do we want to add this paragraph?
TabAtkins: Every usage is bearing angles, but should we require it
or leave it open to be something different in the
future?
Florian: I'm not sure it makes much sense for vague future, but a
note for future authors not to do this accidentally
sounds fine.
TabAtkins: Sounds like not an objection, but you're also happy
with a non-normative note.
TabAtkins: So objections to it must be bearing angles?
ChrisL: Can you say exactly what you mean by bearing angle?
TabAtkins: Bearing angles means 0deg is pointing north and
positive is counter-clock.
ChrisL: Then east and north need to be in terms of coord system.
TabAtkins: Yeah.
TabAtkins: The few uses of angles in SVG match this, the old oral
style sheets match, polar match.
ChrisL: If all existing uses match, that's fine.
TabAtkins: So objections to me requiring that across specs? Or are
we okay with spec doing what they need to.
<ChrisL> require is good at this point
fantasai: I think we switch this to a note saying it's a
convention in CSS and that will prevent the wrong way.
Florian: I'm not convinced it makes sense to have normative things
apply to spec authors.
TabAtkins: It's the same as saying a pixel is a certain lengths.
This is saying how angle is used.
fantasai: Pixel is the same everywhere, but angle is sometimes
direction, sometimes rotation, etc. I think it's not
quite the same because it can be different. Transverse
goes the other direction, is that not a bearing angle?
TabAtkins: So you just said we use angle units as different things.
But angles as directions we can give a consistent
meaning.
fantasai: It's not 100% clear what's a direction. Obvious hue is
unrelated, but transforms I might think of as direction.
Florian: I won't object, but I'd prefer a note.
TabAtkins: We'll go for a note.
Review of calc() serialization principles and spec prose
--------------------------------------------------------
<astearns> https://drafts.csswg.org/css-values-3/#calc-serialize
fantasai: TabAtkins...there was an e-mail saying that the
serialization for calc() isn't defined, TabAtkins said
he'd write it, he did, but there's been no review. So
would people who care about this please review.
TabAtkins: I did base it off some study, there is one bit missing
where if you're going to get clamped, it doesn't go
negative. That needs to happen between steps 1 and 2 of
the current algorithm.
fantasai: The point is, please review and lets come back.
astearns: Any comments right now?
fantasai: I'd be happier publishing this to CR if there was a
positive review from someone other than me an TabAtkins.
I was planning on that this month.
<Bert> (Minor remark on serialization text: The parentheses in
"(Terms with a value of zero must be preserved in this
summation.)" should probably be removed.)
Add <foo-percentage> combo productions
--------------------------------------
TabAtkins: I thought we agreed on this as a WG.
fantasai: Sorry, I missed that resolution.
Defer toggle() to level 4?
--------------------------
fantasai: Does anyone implement toggle()?
fantasai: Apple? MS?
<gregwhitworth> we don't
fantasai: Do I assume no?
fantasai: toggle() functional notation?
Rossen: We don't implement that.
Rossen: Was the question do we or are we planning to?
fantasai: If no one implements currently I think we should push to
level 4 and wrap up level 3.
Rossen: I'm in favor of that. That wouldn't slow us if we want to
implement.
smfr: Webkit doesn't implement.
fantasai: Okay. I'll remove it once we have a level 4 draft.
<dbaron> Maybe level 4 would be a delta spec for some period of
time?
astearns: Anything else on values and units?
fantasai: Nope. Please review serialization.
gradient rendering & image-rendering property
---------------------------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0017.html
astearns: This is something Amelia brought up.
smfr: This suggested image-rendering should effect gradients as to
if they show banding or what have you. My reaction was for
webkit we don't have the knobs for rendering. I'm not sure
it makes sense, I'd prefer gradient looks good everywhere.
Florian: I'm not sure just looks good is the point. In different
context looks good means different things.
MaRakow: I'd agree with smfr. In general we get more complaints
about not having support than you would expect.
TabAtkins: The only thing that justifies the switch is if you have
perfectly vertical stripes and they don't align to
pixel bounders. But that's so low profile...if we can
make gradient rendering look good in general we should
do that.
Florian: That's the main one. Also if your stripes or horizontal
or vertical, you don't want the algorithm to dither your
stripes completely.
TabAtkins: That can't happen. Stripes are a solid color region.
Dithering is during a gradient region when you're
actually ramping the color do you use algorithm.
ChrisL: It's dithering to avoid mach-banding.
Florian: As we get higher resolution the slightly fuzzy problem
gets smaller.
smfr: One consideration, if our graphics could do high quality but
expensive to render, maybe that could be opt-in.
TabAtkins: When that happens, implementors can create ridge
rendering to support that.
smfr: I don't want image-rendering to apply to gradients. So if
you say pixelated do you turn off.
TabAtkins: Pixelation controls scale...no...I see it. Image
rendering is sole scaling quality so technically
wouldn't apply to gradients. This can be re-written to
apply to image generation. I don't think anyone can
differentiate. If they do later we can make the small
spec change.
astearns: So, the people who have an opinion here, can you please
reply to the thread? It would be good for people
participating on the mailing list get that feedback.
That we can't do it now and in the future it might not
be as much an issue.
Layout containment and overflow
-------------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0034.html
Florian: When you're applying layout containment, but not paint
containment, if we do as specced it doesn't work...if you
have something overflowing from layout container it can
go so far out it causes a scroll bar to appear.
Florian: That scrollbar causes layout problems. We can say layout
containment is also paint containment. Or when you have
layout overflow it's paint overflow and therefore doesn't
have scrollbars.
Florian: Do does that sound reasonable? Do people who implement
this have another way out?
TabAtkins: The correct solution is stop having layout effect
scrollbars, but I've been beating that drum for 5 years.
Rossen: In general I would agree layout containment should be
stronger than paint containment. So if I was writing those
in priority order I would consider layout first for both
scrollbars and overflow affecting other layout.
Rossen: So one way out is to be explicit that for paint layout
containment it resolves in paint containment.
Florian: It works, but it's not good. So if you're doing layout
containment it's not clear you want shadows clipped.
There are cases where it's fine to have overflow, but
there are times that it does effect containment.
Rossen: I haven't thought about this too much and we haven't
implemented so I can't comment.
TabAtkins: We're in the middle of implementing. I'll ask our
implementor what he thinks on it.
Rossen: That would be great.
fantasai: If I recall correctly Mozilla wouldn't have a problem
doing paint contain if you have layout, but I don't know
if it's user friendly. It's better than clipping to
contained box.
Florian: The only worry...
fantasai: So you're proposals are 1) auto clip to contained box
and 2) allow visible overflow, but if it overflows the
parent scroller you can't see it.
Florian: Yes.
fantasai: Between those two, I'd go for showing more content. That
seems to make more sense to me. You're less likely to
clip things the user wants. And how we handle it in
Mozilla I think that's straightforward to implement.
Either would be easy to implement.
Florian: Before we conclude, actioning tab to look at his
implementation is good.
ACTION TabAtkins ask his implementor about layout containment and
overflow.
<trackbot> Created ACTION-757
<TabAtkins> sent the email, will report back when I get a reply.
-webkit-user-select
===================
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0050.html
* tantek quickly reviewed the agenda, and has only one comment,
which is to support Florian's proposals re: css-ui-4
-webkit-user-select as noted:
https://lists.w3.org/Archives/Public/www-style/2016Feb/0050.html
Florian: User-select is implemented all over and with the webkit
prefix it's also all over.
Rossen: IE doesn't have it, Edge does.
Florian: It's being implemented by other than the webkit family of
browsers. So this is a bit like we said about word-break:
break-word where if it's needed for compat it should be
in a spec. So I'm proposing that it should be in CSS UI
in a compat section.
fantasai: In this case I don't think we do an appendix and put it
inline with an actual definition as a short hand or
parse time alias. One sentence at the bottom that says
UAs MAY implement, authors MUST NOT and at some point
this may be removed. That'll call a lot less attention
to it.
fantasai: The other one we needed a definition, but in this case
it should be one line of normative prose. So the UAa may
implement if they feel it's necessary for compat, it's
not guaranteed to stay implemented.
Florian: In general when something is clearly required for web
compat, I'm not sure there's value in may.
fantasai: There may be CSS implementations not interacting with
the web, like Prince, they have no reason to implement
this. An e-book reader may not care.
Florian: This property isn't implemented without a prefix. It may
shift some web content once that happens. Here I'm okay
with a may.
astearns: Objections?
Florian: Additional data, the whatwg is doing this too, but they
are happy to drop once we have it.
astearns: I'm happy to have it in our spec. tantek mentioned in
IRC that we should spec.
TabAtkins: We should spec it.
smfr: For impl with -webkit-user-select, how compatible is that
with the unprefixed?
TabAtkins: I don't think we have a difference.
Florian: The differences are irrelevant for difference and used
for none.
smfr: So the spec will say only none or it's a synonym.
Florian: That was my plan.
smfr: I think we have very different behavior for user-select: all.
<gregwhitworth> looking through bugs this morning it was mainly
focused on the none value
Florian: There were differences on other values that were
mentioned in spec. My assessment was this wasn't
different enough for compat problems. It wouldn't cause
breakage.
Florian: Based on that people can align. If you're finding that
the -webkit is different and you need to preserve both,
that's something I'd like to know.
smfr: I don't have data. I seem to recall in the past people had
discovered incompatibilities.
Florian: I found differences, but not ones that caused
incompatibility.
smfr: So UAs other than webkit; would you expect them to take all
the values?
Florian: I would not. I think syntax level alias is sufficient.
smfr: I'm fine if the other vendors agree.
Florian: Draft doesn't specify -webkit, just a behavior.
astearns: Should the draft say people may implement this syntax
level alias because web compat is required for the none
value and mention there's no need to have other
implementations match -webkit-user-select on the other
values?
astearns: Or is that too much detail?
Florian: Overkill.
Rossen: I'd agree.
Rossen: In general we're implementing whatever makes the web work
and we don't go into implementing everything that's in a
webkit prefix if no one is using it.
astearns: smfr are you okay with what's been proposed?
smfr: I guess so. It sounded like Rossen was arguing it's not a
pure synonym and it would make sense to only say the common
values.
Rossen: And it would give a way to deprecate them.
fantasai: We can do that. We do something similar with page-break
where the values map to a subset of the break values. If
there's only one or two on -webkit that we care about we
can say only those are alias and the others invalid.
Florian: I'm not against, but I don't think that's what's being
implemented. I don't want to spend extra work writing
what's not being done.
Rossen: So speccing only the fully interop set makes sense. The
perfect example is all gregwhitworth's work with tables.
It's not meant to describe new behavior, it's documenting
status quo.
Rossen: If you spec more you're encouraging interop gaps.
Florian: So I'll need to test...there's one value only on IE and
Edge and I'm not sure if it's alias to -webkit
Rossen: I have to go and check.
smfr: webkit doesn't support contain. Just auto, none and all.
Florian: Yes, that came from Microsoft. So do they support it
though the prefix.
Florian: I'm in favor to just spec reality. If non-webkit just
alias I'll spec that. If they only do the restricted set
I'll do that.
RESOLVED: Spec some set of -webkit-user-select values.
ACTION Florian determine set of -webkit-user-select values to spec
<trackbot> Created ACTION-758
fantasai: Florian may want to come back with his set. We have
'what's implemented' and 'what's needed' and we're not
sure which set. Rossen is what's needed and Florian is
what's implemented.
astearns: Even if there's a larger set implemented we should only
spec it if it's interoperable.
Florian: I don't think interop is a problem here.
Florian: I can't evaluate if extra values are needed. I take it if
other browsers implement them, they are. So that's why I
want to spec what the browsers do.
Florian: If spec what they do isn't right, some one else needs to
decide needed.
fantasai: Can Rossen or gregwhitworth figure out what's needed for
-webkit-user-select?
<gregwhitworth> sure - I'll take it
ACTION Rossen figure out what's needed for -webkit-user-select
<trackbot> Created ACTION-759
astearns: We are done.
<Florian> Just checked, and both Edge and Firefox do a direct
property name alias on -webkit-user-select, meaning that
they support under that prefix all the values they know
about, including the ones webkit never supported.
<Florian> So Firefox supports "-webkit-user-select: -moz-none" and
Edge supports "-webkit-user-select: element"
Received on Thursday, 18 February 2016 00:51:10 UTC