- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 4 May 2017 00:10:17 +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.
=========================================
Spec Rec Next Steps
-------------------
- Writing Modes: fantasai will confirm that the proposed edits are
okay.
- Fonts: Myles has finished changing the test font.
- Values & Units: fantasai will confirm the DoC is ready for
republication.
- Transforms: Rossen will ask Bogden to help smfr with edits.
FPWD and shortname for CSS Logical Properties & Values
------------------------------------------------------
- RESOLVED: FPWD of Logical Properties with a short name of
css-logical
Suggestion: "Overflow styling" / Scrollbar styling
--------------------------------------------------
- There was a lot of browser interest in achieving compatibility
on this feature since it's used widely enough that it can't be
removed.
- smfr had an explainer of the implementation
(https://webkit.org/blog/363/styling-scrollbars/) that the
Edge folks will review to see what additional information
would be needed to make a compat spec, which would likely
be added to CSS UI4.
- Anything extending beyond compat will be deferred until working
group members have a better understanding of what's out there
now.
Avoiding accidental double spacing
----------------------------------
- The issue on defining/standardizing line-height: normal
(https://github.com/w3c/csswg-drafts/issues/1254) needs to be
resolved before this issue can be resolved.
- myles will write a test font to help make the test cases for
line-height: normal more robust.
Should flex-shrinking propagate back down the flex chain?
---------------------------------------------------------
- fremy will file a bug on the appropriate browsers.
Porting gradient midpoints to Level 3
-------------------------------------
- RESOLVED: Move gradient midpoint to Images L3.
Clarification about `Nx` as <resolution> value in image-set() is
needed
----------------------------------------------------------------
- RESOLVED: Add the x unit to <resolution> type in Values & Units 4.
- RESOLVED: Revert the edit to image-set in CSS Images.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017May/0004.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Elika Etemad
Robert Flack
Simon Fraser
Daniel Glazman
Tony Graham
Dael Jackson
Brad Kemper
Peter Linss
Myles Maxfield
Thierry Michel
Michael Miller
Theresa O'Connor
Liam Quin
Florian Rivoal
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Lea Verou
Greg Whitworth
Regrets:
Benjamin De Cock
Scribe: dael
Spec Rec Next Steps
-------------------
astearns: Writing modes. 2 issues. One closed yesterday. Last is
editorial.
astearns: fantasai, was my proposal to shift things acceptable?
fantasai: I was thinking about it, but we can probably rejigger
like you said.
astearns: If you can make that edit asap there's nothing keeping
us from PR.
fantasai: Okay.
Florian: CR first.
astearns: Republishing first, yes.
fantasai: These are editorial. I don't think we need CR.
astearns: Not those, but we haven't done the edits from the last.
fantasai: Those were dropping.
astearns: That's fair. I'd have to look at the change list again.
astearns: Let's do that once you get the last edit in.
astearns: Fonts, myles was changing test font.
myles: I think I've finished all the changes.
astearns: You made the changes to work in Edge. There were extra
feature requests. They're done?
myles: Yes.
astearns: Great.
astearns: There were a bunch of specs, cascade, conditional rules,
backgrounds & borders where dbaron was going to look at
adding test from Mozilla after F2F. Can you get that on
schedule?
dbaron: Possibly, but I haven't yet.
astearns: On conditional rules we were going to resolve CSSOM
discrepancies. Did we at F2F?
Rossen: No.
astearns: I'll get that on agenda soon.
astearns: Values & Units- Simon did changes. Anything else before
we publish?
astearns: Who is an editor for that?
fantasai: I am not 100% sure. I have to double check the DoC is up
to date. Think it was.
astearns: I'll put you down as checking what needs done before
publish.
astearns: Transforms. Made a lot of progress on issues, but most
are open and awaiting edits. Who will make those?
smfr: I need help from an SVG person. [missed]
Rossen: If AmeliaBR gets invited expert with the group she can
help you. If not I'll have Bogden take another look to
help.
astearns: I would like the work to start with Bogden. We'll get
AmeliaBR quick hopefully, but she's finishing a book so
I don't think we can expect editorial from her soon.
Rossen: Reasonable. Since Bogden is part of WG we're good to go.
astearns: Anything more on Flexbox? There were a couple issues.
Rossen: We have some of the issues on the agenda.
astearns: Okay. Let's go with that.
astearns: CSS UI fantasai was reviewing test updates. Have you had
a chance to do that?
fantasai: I haven't.
astearns: That's it on my list. Thanks for the updates.
FPWD and shortname for CSS Logical Properties & Values
------------------------------------------------------
fantasai: The draft is, I believe, up to date with all resolutions
so we should FPWD. We hadn't before because the draft
was incorrect. Needs a short name. It's currently
logical-props but we don't tend to abbreviate in short
name.
fantasai: I was wondering if there's a better idea.
Rossen: We had a resolution from before to publish WD with CSS
logical-props short name. I can dig out the resolution.
fantasai: We haven't done FPWD so if someone has a better idea it
would be nice to not have props.
<dbaron> css-logical-properties? css-logical?
<bradk> [logical]
astearns: logical-properties is logical, but not short.
fantasai: I'm okay with css-logical.
<tantek> css-relativity
fantasai: I'll note the correct term is flow-relative directions.
We might add other mappings in the future like line
relative. They're text based.
fantasai: There's a certain amount of expansion in that direction
so relative is more accurate.
<jensimmons> css-directions?
<dbaron> css-relative-properties?
fantasai: We might have directions relative to the line direction.
Or relative to the page, like inside outside.
fantasai: Relative seems to be the commonality. flow-relative is
in the prose. This is just that future levels may have
relativity.
<tantek> css-logical?
Florian: We've been using physical/logical distinction quite a bit
so if we're stuck with that it's not that bad.
<fantasai> My top contenders are css-relativity and css-logical
astearns: Relative confuses me with relative positioning.
Rossen: So css-logical as the short name and proceed with
publishing? IS that what we're trying to take?
astearns: Objections to using css-logical as a short name for
Logical Properties?
astearns: Objections to FPWD?
RESOLVED: FPWD of Logical Properties with a short name of
css-logical
Suggestion: "Overflow styling" / Scrollbar styling
--------------------------------------------------
Github Topic: https://github.com/w3c/csswg-drafts/issues/107
Florian: Based on previous conversations I think we want to
reject, but I want to check.
Florian: Request is for pseudo elements to style parts of the
scrollbar. I believe browsers don't want to give authors
control since they're native UI components and therefore
we should reject. If that's not the case let me know.
MaRakow: I think the main interest I have from Edge is along lines
of interop. There were suggestions of enhancements that
I'm not sure about, but -webkit-scroll we see getting
used on certain sites. We'd be interested in a compat
spec to explain behaviors.
MaRakow: I'm not certain about going beyond what's there.
astearns: MaRakow are you interested in having webkit behavior
specified or do you want something interoperable specced
so everyone can do non-prefixed?
MaRakow: The former because we see it used. Once I understand
what's going on it would be easier to comment on second.
But it's more if sites like gmail are using this how do
we get interop render of gmail on multiple UAs?
dbaron: One other question is that there are cases where devs are
rebuilding scrollbars from scratch because they don't have
this. That creates performance and UI problems that this
would avoid. There are tradeoffs.
<jensimmons> I totally agree with dbaron. Yes. All the custom
scrollbars / forms and the slow slow JS. ;(
* liam too, and also accessibility problems with home-made
scrollbars
MaRakow: We see those too. I have less understanding of the exact
requirements. I think a compat spec around webkit
functionality and if the experts have any learning that
would be valuable. I wouldn't oppose understanding
better, but there's more expertise on the people who
worked with existing webkit.
<TabAtkins> I'm using ::scrollbar, ::scrollbar-track, and
::scrollbar-thumb on a personal website, to make a
less obtrusive scrollbar for a minimal blogpost editor.
fantasai: There's a lot of talk about different things related to
scrollbars. This is about having selectors, not
properties, for each piece of scrollbar.
fantasai: This is about having selectors to style piece of
scrollbar. What you guys are talking about seems broader.
fantasai: This issue we need comments on and then we can talk
about more things to control scrolling behavior and bars
and stuff.
<TabAtkins> #post::-webkit-scrollbar { width: 2px; }
#post::-webkit-scrollbar-track { background:
transparent; } #post::-webkit-scrollbar-thumb
{ background: #eee; }
Rossen: I think what you said covers the GH issue. It also aligns
with the compat observations we have.
Rossen: It is mostly those pseudo classes effecting the way the
experience is different between webkit and everyone else.
Rossen: If the folks with experience on those particular
properties can come up with an explainer or compat spec or
anything that will help us understand we would be very
interested in impl those, prefixed or not we don't care at
this point as long as we achieve compat.
<glazou> let's be serious, there have been proprietary selectors
for that for AGES.
<glazou> and the web is full of them
<glazou> a lot of sites use those pseudos to "style" the
scrollbar, in particular often for a color matching the
corporate color
<glazou> Orange using it a lot IIRC
Rossen: The second part of this is once we get past styling there
is a whole scrollbar customization people want to do like
going into the scrollbar and adding marks like to show
where changes are. Those are fairly advanced which people
are hacking today. We're be interested in pursuing that,
but it's more expensive and an advanced scenario.
Florian: If we just get the pseudos, before we get to fancy it
seems we would not be anywhere near done because we'd
need to say which properties do what and what the default
UA is. You can access the thing, but does the scrollbar
change if you change the width of scrollbar thumb.
* fantasai suspects making the scrollbar too narrow can be an a11y
problem
<bradk> Tick lines in the scroll bar could be done with
linear-gradient background
<jensimmons> believes what projects want the most is the ability
to ‘brand’ it — change color, remove gradients, etc.
Visual styling.
<glazou> +1 to what jensimmons wrote above; exactly what I said
above
<Florian> suspects that :scrollbar-track { position: absolute;
top: 50%; } is not going to do interoperable things
Rossen: This is where it goes back to webkit and blink supports
that. For your question, yes they would change the
scrollbar. We're interested in their experience in
supporting those properties. I'm interested in hearing
from webkit folks who are often resistant to control
customization.
Rossen: Also they have the most experience.
Rossen: Is there anyone from webkit who can speak to that?
smfr: The scrollbar styling they tried to implement for itunes.
smfr: It was a mistake to leak to web. We don't really like that
people can style scrollbars. We won't enhance and prefer to
deprecate it.
smfr: Other thing is pseudo elements become artifacts because
platform changes scrollbar. For example we don't have arrow
at bottom of scroll for map and when you try to style it
it's not there. That's the general take.
astearns: So item was on agenda to close this. I don't think we
want to close and not fix. I've heard people want more
info about what's currently prefixed, but I don't hear
anyone to work on it.
fantasai: As long as Safari & Blink ship this there will be
pressure on other browsers to impl. We need to decide if
that will be removed or we'll have to standardize. You
can't say we're going to deprecate. You have to either
remove it or add it to the platform. The pressure will
increase over time.
MaRakow: I agree with fantasai. I'd be happy if selectors are
removed. My goal is interop if that's achieved by
everyone impl or if everyone removes. I'm not interested
in prop for own merit, but interested in interop of
rendering.
astearns: I'm guessing browsers with it can't commit to remove.
TabAtkins: Oh no. We can't remove. They're used more than possible
to kill.
Rossen: Can you explain them?
Rossen: Like write an explainer or compat spec so impl that don't
have it can add that behavior? We'd be happy following the
behavior if we get compat.
TabAtkins: In theory yes. I can put it at the end of my current to
do list.
<smfr> explainer here: https://webkit.org/blog/363/styling-scrollbars/
Rossen: I didn't mean you personally.
Florian: I'm curious. Would people really impl them? These are not
properties, they're selectors. Are people really willing
to make people able to relpos the thumb of a scrollbar?
TabAtkins: They're restricted.
Rossen: We're willing to impl whatever gets us interop. I'm pretty
sure that doesn't mean having relpos and grid in a scroll
bar. That's why we want the browsers with support to give
us MVC of supporting that.
astearns: smfr posted a link to a blog that desc them.
astearns: Could someone from Edge look and see how much more would
be necessary to get compat impl?
Rossen: We'll review it.
Rossen: For purposes of this topic what if we end here. We'll
review and bring back if we need more info.
astearns: sgtm
Rossen: There was the question if this goes into UI4.
Florian: That was one possibility. CSS UI hasn't had selectors so
I'd prefer somewhere else.
fantasai: I Think UI4 makes sense due to specificity of selectors.
fantasai: As far as what we need for more info, we need a full
spec for things you want to add. We need a proper set of
standard aliases. You don't get compat...you can't say
this won't be part of the platform. If we're not
removing then we're adding it's part of the platform.
Florian: The question is do we have enough info in the blog to
make a spec. I would say we don't because it doesn't have
a per pseudo class whitelist of properties that apply and
if it's unusual, how? Because otherwise I can put grid in
the scrollbar track.
<fantasai> +1
astearns: That's as much time as we should spend. We have
something to start with.
Avoiding accidental double spacing
----------------------------------
Github topic: https://github.com/w3c/csswg-drafts/issues/938
Florian: I think we shouldn't rehash that issue in github. I think
we need to sort out another issue first. We had been
talking about what line-height normal means at F2F and
discovered we don't even know what line-height: number
means.
koji: There are details to get out. As long...in terms of
line-height consistency, I think dbaron confirmed it's
consistent.
Florian: I don't think we concluded. WE said prob is, but we have
3 behaviors on the white board. We weren't sure.
<fantasai> diagram:
https://lists.w3.org/Archives/Public/www-archive/2017Apr/att-0008/IMG_20170421_173959.jpg
koji: All on consistent for line-height
Florian: No they're not.
koji: They were.
Florian: 2 are, one isn't.
Florian: The black behavior does not result in the same
line-height as blue and red.
Florian: We weren't sure which Edge did. We didn't have full
answers.
<dbaron> Only one of the three is consistent for line-height if
you have font fallback
Florian: My proposal on double spaces depending on line-height.
koji: I think I have tests on this already.
Florian: If you have tests, when were they shared?
koji: In this issue.
koji: As far as I tested it's interop.
<Florian> https://github.com/w3c/csswg-drafts/issues/1254
Florian: When we discussed at F2F no one knew for sure. If you do
know, ^ is where we discussed that.
astearns: koji can you post a link to your test cases?
<koji> http://output.jsbin.com/xekuhu
Florian: Okay.
astearns: koji can you describe what it's checking?
koji: This is a test case we discussed. 5 in the graph- first is
line-height: normal. You can see the line-height is same. If
you have 5 line-height options it's maybe different. You
have 0, 1, 1.2, 1.5, 1.8.
koji: You can see it's consistent height.
<Rossen> https://lists.w3.org/Archives/Public/www-archive/2017May/0000.html
<dbaron> Does this testcase have font metrics that would trigger
the issues we discussed?
Florian: I can't figure out which browser is what color.
fantasai: You need a case with fallback in the line. Where you
have difference scripts all on the same line. Have that
trigger different fonts with different ascent & decent
metrics.
myles: You need a font with crazy high and crazy low ascent/
descent.
Florian: I think this is a bit too tricky on the fly. Until we
call agree what line-height: number and line-height:
normal means it'll be hard to solve.
Florian: If we agree enough that size is the same that could be
enough to discuss. Documentation about behavior isn't
there.
koji: I thought [missed]
astearns: I think I heard you say browsers agree on line-height,
but not glyph-position in line-box. Correct?
koji: Yeah. One this we agreed is to match existing impl. If they
all agree on line-height: number I don't see problems.
Florian: I don't think we established they agree.
fantasai: We said impl will agree if they conform to CSS2 because
we agreed to change CSS2 to say that the black behavior
is not allowed. So if impl follows spec line-height will
be that number. If impl don't follow they have to change.
dbaron: I don't think that's what we agreed.
Florian: I think that was a preliminary conclusion.
dbaron: I think what we agreed only produces it if there's a
single element. It doesn't work if there are multiple
elements on the line when some have font-fallback.
astearns: Did I hear myles volunteer to make test fonts?
myles: I can do that easily.
astearns: Thank you.
astearns: I think we need to get past this question about what
CSS2 will say about line height and if implementation
will be able to match. Then figure out cases where
that's not enough for consistent line height.
astearns: Seems they're pre-requisite to figure out step height.
* fantasai agrees with astearns statement
astearns: koji is it alright to move on?
koji: Yeah. I'll re-read the discussion.
astearns: I would like to see progress. I'll see what I can do to
get that going. I think myles making the fonts will be a
big help.
<Florian> agreed
Should flex-shrinking propagate back down the flex chain?
---------------------------------------------------------
Github topic: https://github.com/w3c/csswg-drafts/issues/1290
fantasai: I think this was fremy's. I haven't dug in much.
fremy: The issue is probably a chrome bug, but I waned to check.
fremy: Someone made a lot of good test cases. I agree with the
explanation he gave. What he said makes sense. But if
you're not ready to discuss I don't know if anyone is ready.
fremy: I can go ahead and file bugs and if it doesn't match spec
the browsers will complain. Or we can wait. What do people
feel?
astearns: I think you should file a bug. It's often the fastest
way to determine if it's a spec bug or can be fixed.
fremy: I was just trying to get feedback. Seems like it's probably
a bug. If WG says file a bug I can.
astearns: Anyone from Chrome with an opinion?
TabAtkins: I can't look, so no opinion right now.
fremy: Summary: when you have a flexbox in a flexbox and inner is
auto. In all browsers except Chrome you size the flexbox
normally. The fact that it's a flexbox in a flexbox effects
size in Chrome.
fremy: I'll file a bug. We can discuss later if they come back.
Sound good?
fantasai: Yep.
astearns: We'll file a bug and see how that goes.
Porting gradient midpoints to Level 3
-------------------------------------
Github topic: https://github.com/w3c/csswg-drafts/issues/1284
astearns: I thought that the midpoint implementors were the same
people, but I forgot we tasked a person in a different
continent to implement in one browser. We do have two
implementations.
<Florian> go for it then
TabAtkins: I'm down with it.
astearns: Objections to moving gradient midpoint to L3.
RESOLVED: Move gradient midpoint to L3.
Clarification about `Nx` as <resolution> value in image-set() is
needed
----------------------------------------------------------------
Github topic: https://github.com/w3c/csswg-drafts/issues/461
astearns: Question if this is editorial or needs a resolution.
leaverou: In image set it allows values of 1x that is same as
1dppx. Even though the image example had it, it wasn't
part of grammar. We solved that by adding an
x-resolution. So issue was addressed. It's grammar, not
syntax.
leaverou: It's another question as to if it should be added, but
that's V&U. As far as images is concerned grammar is on
par with example.
fantasai: Do we want to add this to <resolution> type?
TabAtkins: I've been for that for a while.
leaverou: I'm not sure it's a good idea to take a single letter
unit for a shortcut to another unit.
TabAtkins: We've done that. We won't use it elsewhere now.
leaverou: Then it is a better solution to add to the <resolution>
section.
fantasai: We've never had alias units, so what do you get if you
serialize it back out.
leaverou: dppx?
TabAtkins: It's only image resolution and webkit image set, so
let's see what webkit does and do what they say. It'll
be x or dppx.
smfr: Pretty sure it's x
* hober would be surprised if dppx worked there
fantasai: If you put in dppx do you get out x?
TabAtkins: In specified style no. We don't need fancy. They're
different units with a 1 to 1 ratio. In computed when
you canonicalize you go to probably x.
* fantasai wants to hear dbaron's take on this
<fantasai> https://www.w3.org/TR/css-values-3/#resolution
<dbaron> I'm trying to think about whether "x" makes sense for all
uses of <resolution> or just some of them.
<dbaron> I think it's probably all.
Florian: What if you animate from one to the other?
TabAtkins: Over computed values and all resolutions can be
computed to each other.
astearns: Are we converging on using x everywhere <resolution> is
possible?
TabAtkins: Let's leave that to testing. But do we add x to
resolution and I'm a +1 to that.
astearns: Do we want to resolve before we test?
TabAtkins: Is anyone going to object based on the answer?
astearns: Proposed resolution is add the x unit to <resolution>
type in V&U.
leaverou: Yep.
astearns: Objections?
RESOLVED: Add the x unit to <resolution> type in V&U.
fantasai: L3 or L4?
astearns: I'd be happy for 4.
TabAtkins: It only has one impl.
astearns: Since it would go in 4 it means leave the edit in images
in place because we don't want it to depend on L4 spec.
TabAtkins: Sure
fantasai: It's fine because you would have the impl that supports
L4...the testing would be part of L4 impl. It's like
when we added q unit your lengths had more values
possible.
astearns: Okay.
TabAtkins: Yeah, take it out of image set. It depends on
resolution type.
<leaverou> agreed as well
astearns: Then we also need a resolution to revert the edit to
image-set?
astearns: Objections?
RESOLVED: Revert the edit to image-set in CSS Images.
astearns: We're at time. Thanks everybody.
Received on Wednesday, 3 May 2017 21:11:23 UTC