- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 7 Sep 2016 20:05:16 -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.
=========================================
Apply offset-path to specify the shape of progress element
----------------------------------------------------------
- There wasn't interest in creating a new pseudo-element at this
time. Exploration should focus around custom elements and any
problems in the implementation of SVG that is causing it not
to be performant.
scroll-snap-padding vs snap-padding
-----------------------------------
- This topic will be added to the TPAC agenda.
Grid Issues
-----------
- RESOLVED: Keep the name grid-gap (issue #19).
- astearns filed an issue to add an example documenting the
difference between the space in grid-gap and a traditional
gutter.
- RESOLVED: Have percentages in grid-gap behave as percentages in
tracks (issue #20).
- RESOLVED: Keep auto-flow in the grid shorthand (issue #24).
Block-axis baselines reconsideration
------------------------------------
- Mats wasn't on the call, so this discussion will continue on the
mailing list or github.
Baselines of empty boxes
------------------------
- RESOLVED: Have grid and flexbox keep saying that empty boxes
have no baseline and they're synthesized with bottom
border edge.
Layout containment should make an element containing block for
absolute/fixed positioned elements
---------------------------------------------------------------
- There was general agreement to accept the proposal, but
TabAtkins needed to check with the implementor first.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Sep/0017.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Daniel Glazman
Tony Graham
Jihye Hong
Dael Jackson
Ian Kilpatrick
Chris Lilley
Peter Linss
Thierry Michel
Anton Prowse
Liam Quin
Matt Rakow
Florian Rivoal
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Greg Whitworth
Regrets:
Simon Fraser
Myles Maxfield
Michael Miller
Simon Pieters
Steve Zilles
Scribe: dael
Apply offset-path to specify the shape of progress element
==========================================================
astearns: We can get started and fiddle around with the agenda
until fantasai arrives.
astearns: Anything to add to the agenda?
<astearns> https://github.com/w3c/csswg-drafts/issues/429
jihye: I thought about how to do circular progress bar.
<jihye> https://cloud.githubusercontent.com/assets/6636090/17996451/f54deeb8-6ba3-11e6-8727-91601976bb71.png
jihye: Various shapes and watches and car dashboards use a
circular progress bar. The link above is a picture of a car
dashboard.
jihye: To implement that kind of bar there's 2 ways. SVG or
border-radius. But these have poor performance for a smart
watch.
jihye: There's requests to solve this from LG and other companies.
We have a jquery to implement the circular progress
component, as does Samsung. It would be better to have a
standard. I have an idea about spec the shape of progress
bar using ::path.
jihye: It is used to change the shape of the progress element.
When the pseudo element is applied the path from offset-
path could decide the element.
<jihye> https://cloud.githubusercontent.com/assets/6636090/17996464/0a102c94-6ba4-11e6-9891-30125e15fba6.png
jihye: For an example: for ^ progress bar it could be spec like
<jihye> https://www.irccloud.com/pastebin/s1ghFrZp/
jihye: ^
jihye: Actually, offset-path property spec the path the element
can move. For ::path it spec how the progress path is drawn.
jihye: Is it possible for offset-path works differently?
TabAtkins: I think it's odd for offset-path and you're just using
it because it lets you specify a thing. If we want to
shape progress bars it should be separate property with
similar syntax. Also, some of the existing properties
like angle doesn't mean anything. It's just the basic
shapes and path that do something meaningful. We should
invent something new.
<Florian> +1 to Tab.
astearns: There are some details about a progress indicator that
aren't handled by a shape. A circle could mean an entire
circle that's measured with a wedge for progress. You
have to spec the circumference or if it's the whole
circle or just an arc.
astearns: In your example the watch starts at North and the
dashboard starts at Southwest which would have to be
expressed.
TabAtkins: With motion-path that's the start.
TabAtkins: This could be just a custom element and you put in some
SVG in your shadow DOM.
Florian: I think jihye said there were performance issues with SVG.
jihye: Yes, SVG has poor performance in smart watch. We need
another approach.
TabAtkins: I'd be surprised at not being able to do a circular
path because smart phones do it well now. I would think
it would be the implementation that has the problem.
Rather fix the implementation than us carve a new
version.
bradk: Maybe the SVG rendering version.
ChrisL: Yeah. Remember SVG was implemented on phones before smart
phones, so I think it itself should be okay, but the impl
could be optimized.
astearns: Generally this is an instance of styling controls which
is a long standing thing we've tried to work on and we
haven't come up with anything. As far as I understand
custom elements are the solution for now.
<tantek> Indeed. Styling controls is still really difficult.
Especially default controls.
TabAtkins: Yeah, they are a somewhat solution
<tantek> Agreed that Custom elements / web components are
currently the best approach we have for stylable custom
controls.
<jihye> https://msdn.microsoft.com/ko-kr/library/hh771827(v=vs.85).aspx
jihye: There's is also ::-ms-field pseudo elements that work for
Microsoft. It's for controlling animations of the
indeterminate progress element. It can control how the
indeterminate progress control is animated. Is this also
considered to change the determinate element?
jihye: I understand this is only applied to indeterminate progress
element.
Florian: I think the various pseudo elements browsers have is a
swamp of incompatibility and we should try and not look...
TabAtkins: Indeterminate is a pseudo class.
Florian: That's not what she's referring to.
TabAtkins: Oh! than that's unlikely to be spec
Florian: And unlikely to be merged across browsers.
<tantek> so I disagree with Florian on that
<tantek> e.g. we have ::placeholder
<tantek> we are growing compat and making progress
<tantek> especially with new UI pseudos
<tantek> I wholly reject the "swamp of incompat" categorization.
If that's the case, please file test cases accordingly
that demonstrate it.
<Florian> tantek, OK, interesting to hear, I didn't know there was
good progress on form control pseudo elements.
<tantek> (aside: yes, UI pseudos are hard. that does not mean we
are not making progress with them.)
<tantek> (slow progress yes (on UI pseudos), but I think that's
correct as it's a more conservative reliable approach)
<tantek> (I think more UI pseudos is an area that could use
prototyping/incubation before standardization)
astearns: I certainly think that if we get another instance of
custom styling on a bit of UI that everybody uses it's
something we could talk about moving in natively, but it
needs to be tried in custom element arena first.
TabAtkins: Yeah.
jihye: So can I proceed this idea for the new pseudo element or is
this approach weird?
astearns: I don't think weird, just premature.
Florian: The use case isn't weird but the approach is.
bradk: A different approach is to look at the need to stroke
shapes be it for clip-path or shape-inside etc. It would be
good to stroke those or put a border. And if you have a gap
path that could represent the empty part of progress
astearns: To sum up, We would not like to pursue the pseudo
element at this time, we'd much rather go with custom
element and SVG solution.
jihye: Okay, thanks for the comments.
Florian: At the same time, the use case is valid, so if you can ID
something in SVG or custom elements other than bad
implementation bringing that up to address it is
worthwhile. If it's bad implementation it's worth raising
to different people.
scroll-snap-padding vs snap-padding
===================================
<astearns> https://github.com/w3c/csswg-drafts/issues/395
fantasai: I think we should accept the proposal, MaRakow disagrees.
MaRakow: One question is if other implementors have other input.
Florian: I agree with fantasai and I don't fully understand your
objection, but I think we need a whiteboard.
TabAtkins: I'm mildly leaning toward MaRakow but more time in
person with fantasai would be good.
astearns: Let's get this on TPAC agenda.
Grid Items
==========
Rename grid-gap to grid-gutter
------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/353
fantasai: The grid-gutter argument is designers have been using
that term for forever. For grid-gap it's that we have
column-gap already and it's shorter and easier to spell
for non-English speakers. That's where we're at. The
commenter isn't happy with our argument so we've brought
it to the group.
<gregwhitworth> yeah, keep it consistent with column gap IMO
<gregwhitworth> Jen/Rachel?
<rachelandrew> keep it consistent with column-gap
TabAtkins: I agree with fantasai.
ChrisL: I agree it should stay as gap.
Rossen: I agree.
<tantek> also agree with fantasai. too late to rebikeshed this.
<tantek> I'm going to assert that "gutter" is also an
English-centric term. Do any designers based in
non-English countries use "gutter"?
astearns: Anyone disagree with fantasai?
<bradk> Let's have column-gutter
jensimmons: I'm torn. When I first saw it I had the same reaction
and as I teach it I've used gutter a lot.
jensimmons: I understand the one to be consistent. People should
be using multi-col. I'm undecided. There's a lot of
CSS that doesn't align with design.
jensimmons: It is a big inconsistency with everybody.
tantek: CSS has been inconsistent for a while. e.g. we've never
had "leading" and never will.
liam: We also have things like margins and child margins going on.
Gutter and gap are not quite the same. I think we should
have a note explaining the difference.
<jensimmons> these are good reasons…. let’s document them & tell
people about them
ChrisL: That would be quite good. It would deal with the objections.
* liam notes gutter also used for the binding-margin sometimes
plinss: Gutter is only column usually whereas gap could be used
horizontal.
<rachelandrew> I like the idea of documenting why this is so too.
<liam> gutter also used for the binding-margin sometimes ]
dauwhe: I'm noting what liam said is that gutter is the inside
margin in a spread and it has sided-ness that gap doesn't.
<ChrisL> in particular with a diagram showing how gap plus padding
adds up to the gutter?
astearns: bradk mentioned in IRC he'd like column-gutter.
bradk: I'm not really serious about that. We can't change at this
point.
<tantek> would like see documentation on say "How to set a gutter"
<tantek> that explains the components that could go into a gutter
astearns: I'm swayed by the argument to be consistent and I like
documenting that the gap isn't all of the gutter. What
do you think about adding an example fantasai?
fantasai: If someone can outline it I'm happy to add it. I don't
quite understand.
jensimmons: If column-gap didn't exist I'd lobby for gutter, but
the ship has sailed. I think it's good to document and
it's good to hear so we have a robust answer when
people ask.
astearns: Can I get a volunteer to work up an example that
grid-gap isn't the whole gutter?
Rossen: I don't think this is necessary for the spec to move
forward. We've had this conversation before and we keep
coming to the same conclusion. If examples need to be made
I'd suggest that people who work with the community to do
that, but I don't want to hold up the spec.
<fantasai> +1 to Rossen
<tantek> please file the request for example as a new editorial
issue
<TabAtkins> Yes, just file an issue plz
Florian: Given that it keeps coming up, having an example saying
this is a gap and this is gutter and they're different
and it would help.
<tantek> sounds like Florian just volunteered to file the
editorial issue :D
<jensimmons> I don’t think this idea that gaps and gutters might
be different is the main reason / the only reason… I
heard several good reasons. And don’t think that this
one ‘reason’ has to be documented in the spec. It’d
be better to several reasons — and maybe not in the
spec.
<jensimmons> I agree that it should not hold up CR
Rossen: That's great, make it and blog about it.
fantasai: Rossen is saying it shouldn't hold up CR. We're not
saying don't add the example. We're saying let's not get
hung up on this and when there's an example I'll add it
to the spec.
<jensimmons> +1 fantasai
<tantek> +1 should not hold up CR
astearns: I agree. I'll make an issue.
Verification of percentage gutters
----------------------------------
<astearns> https://drafts.csswg.org/css-grid/issues-wd-20160519#issue-20
fantasai: I want to make sure that everyone has the same
understanding.
Rossen: Percentage gaps, right?
fantasai: Yep.
Rossen: My recollection is we decided that for the purposes of
intrinsic size percentages resolve to 0.
fantasai: It resolves to 0 in one axis and a little different in
another.
TabAtkins: It acts like a track with a percentage.
fantasai: And is empty.
TabAtkins: Yep.
Rossen: I think that sounds reasonable.
astearns: Makes sense to me.
Rossen: Do we specify percentages on gutters in the block
direction resolve from the height? Correct?
fantasai: Yeah that's like percentage track.
Rossen: Okay, good. I'm fine with this. astearns?
astearns: Yep. Fine with it.
Rossen: We don't have a pending resolution for this right?
fantasai: I don't think so. Let's just resolve all the things.
Rossen: That's a great idea
<fantasai> astearns, I need a resolution on the previous issue
astearns: Resolution is to allow percentages in grid-gap and
behave as <percentage> tracks.
Rossen: From model POV they're empty tracks. For other layout they
behave as a track.
<svillar> sorry for chiming in but % in gaps it isn't the same as
% in tracks, we cannot fallback to auto
<svillar> for indefinite sizes
astearns: There's a comment from svillar in IRC [reads]
fantasai: That doesn't make sense. We just pretend it's empty.
Auto has a meaning for empty tracks.
fantasai: I don't see why that would be an issue.
Rossen: I agree with fantasai. It should be the same.
astearns: svillar are you on the call or just IRC?
fantasai: I think IRC.
<fantasai> ous issue as well
<svillar> ah ok so "auto for empty tracks"
<svillar> that makes sense
<Rossen> svillar, that's correct
astearns: Okay. He's getting it.
astearns: So proposed resolution is have percentages in grid-gap
behave as percentages in tracks.
astearns: Objections?
RESOLVED: Have percentages in grid-gap behave as percentages in
tracks.
Rename grid-gap to grid-gutter
------------------------------
RESOLVED: Keep the name grid-gap
'grid' shorthand 'auto-flow' keyword vs 'row/column'
----------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/438
fantasai: When we have a shorthand we take the value from the
longhand and propagate down. When TabAtkins and I did
grids with auto-flow rows we decided that instead of
-row and -column we'd just use auto-flow. The row/column
is implied by the position.
fantasai: The difference the row/column creates is to change to
automatic rows or columns instead of being the template.
To make this more obvious we used auto-flow. This seemed
clearer to us. There we a suggestion from Javier to use
-row and -column. TabAtkins and I lean to not make the
change, but we're bringing it to the group.
fantasai: Did that make sense or do I need to explain again?
astearns: That made about 60% sense.
fantasai: General way the shorthand works is you put row values
first and than a slash and than column values
<fantasai> <row-values> / <column-values>
fantasai: So when you have a grid template you have a fixed number
of rows and columns. That creates an explicit grid.
fantasai: When doing auto-flow and you generate as you create
items, you want to be able to control the track sizes.
That's the grid auto-columns. To assign those into the
grid shorthand we need to show we're not going into
template value. We're doing that with the auto-flow
keyword with length etc. keywords are for the
grid-column/row based on the slash.
fantasai: If we used grid auto-flow we could use on of the
keywords that are a value of that instead of auto-flow
keyword.
fantasai: We're impl the position and we're not emphasizing that
the lengths are setting an auto thing not a template
thing. That's why we added this keyword as a switch in
the short hand that doesn't appear in the long hand.
<TabAtkins> In other words, "20px 30px / column 30px" doesn't
really indicate "columns are auto-flowing and get
repeated as necessary"
<TabAtkins> But "20px 30px / auto-flow 30px" does, or at least
does it better.
astearns: In the issue Javier said he doesn't have a strong
opinion. Anyone else have a strong opinion?
[silence]
astearns: Giving silence I'm inclined that we keep auto-flow.
astearns: Objections?
RESOLVED: Keep auto-flow in the grid shorthand.
Block-axis baselines reconsideration
====================================
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Sep/0008.html
fantasai: Mats disagreed with our resolution to say there's not
baseline in the block axis. We can try and make that
work, I think he's implemented. I don't know if anyone
wants to add anything to that discussion, it's on
www-style. I can try and make that work and we can
decide if we want to go in that direction. Mats isn't
here.
astearns: Any possibility he'll be at TPAC?
fantasai: Almost certainly not.
astearns: Looks to me this needs more discussion. Anyone on the
call have anything to add?
astearns: Anything to do now, or move on?
fantasai: Go to the next
Baselines of empty boxes
========================
<astearns> https://github.com/w3c/csswg-drafts/issues/439
fantasai: There's a bunch on inconstancies in how empty box
baselines are handled.
fantasai: Tables are undefined in 2.1. Block containers for inline
layout use bottom margin edge.
fantasai: My vague suggestion is if a box is empty it doesn't
have a baseline and the context sets one. The synthesis
rules we set are different than the ones for inline
layout.
astearns: So we don't change grid or flexbox, but add details to
align.
fantasai: Grid and flexbox say use bottom content edge because
that's the closest we can get to the content. It might
make more sense to be more consistent with block
containers than try and do something no one implements
and it's not consistent.
Rossen: Didn't we agree we want to use border box edge?
fantasai: Yeah. That's what I'm saying for flex and grid.
Rossen: I'm reading your second comment on the issue and it makes
sense. I support that.
fantasai: That works. When I made the changes for the last
resolution it ended up being a separate set of changes.
Rossen: Does 2.1 or 2.2 spec that the inline formatting content
uses...
fantasai: The margin-box.
Rossen: Okay we're fine there.
Rossen: For anything out of inline formatting context baseline is
synthesized based on the border box. That should cover them.
astearns: Where is that defined?
Rossen: CSS align or individual specs if they decline from this
definition.
fantasai: It'll be partly in inline and partly in grid and flex
specs. Grid and flex will say an empty doesn't have a
baseline and one is synthesized. I checked those changes
in. It is a change from what was there.
astearns: Fine with me Rossen is okay. Anyone have a concern?
astearns: So have grid and flexbox keep saying that empty boxes
have no baseline and they're synthesized with bottom
border edge.
astearns: Objections?
RESOLVED: Have grid and flexbox keep saying that empty boxes have
no baseline and they're synthesized with bottom border
edge.
astearns: And CSS align and CSS inline edit to match what we
defined here.
astearns: Well, inline does as defined as 2.2.
astearns: Anything more?
fantasai: As far as I can tell no.
Layout containment should make an element containing block for
absolute/fixed positioned elements
==============================================================
<astearns> https://github.com/w3c/csswg-drafts/issues/404
dbaron: I filed the issue, but Florian added it to the agenda.
dbaron: I don't entirely understand Florian's comment. Basic issue
is I was looking at something for layout containment and
concluded we can't do the optimizations unless layout
containment says that it creates a containing block for
absolute & fixed elements.
dbaron: If it's not you can have elements inside that are laid out
relative to something that's an ancestor. Or partly to an
ancestor and partly to something inside an element. So I
think they should just be containing blocks.
dbaron: Florian seems to think there's another solution?
Florian: I think I misunderstood your point. I thought you said
the child could influence something outside, but you're
saying what's outside is influencing so I think you're
right. I now agree with you.
TabAtkins: I find the interpretation interesting. I didn't assume
containment was a two way boundary. I thought nothing
inside should affect outside. I didn't intend the other
way. That said, I'm not opposed to it. I'd like to chat
with ojan real quick, but I'm inclined to agree with
you. I just want to check with our implementor.
dbaron: Okay.
astearns: Sounds like a good way forward. Other comments on this
issue?
astearns: We're done with the agenda? Anything for 7 minutes?
astearns: Alright. Just a reminder to add items to TPAC agenda.
astearns: Thanks for calling in!
<jensimmons> thank you!
<rachelandrew> thanks :)
Received on Thursday, 8 September 2016 00:06:27 UTC