- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 7 Dec 2016 23:24:25 +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.
=========================================
F2F updates and call schedule for 2016 holiday season
-----------------------------------------------------
- The F2F meeting in Japan is confirmed for 17-21 April.
- The telecon on 28 December is canceled. 21 December and 4
January are currently planned to occur, but members should
keep an eye on the private list.
Future work of FXTF specs
-------------------------
- The specs that were a part of the FXTF are now the sole
responsibility of the CSSWG.
- Rossen will investigate the best way to move the specs in the
CSSWG drafts & github repo making sure to preserve spec
history and issues.
Stretching image grid items in both dimensions
----------------------------------------------
- There were two options for how to address when an image is
stretch in one direction and has a value like center in the
other direction.
1) It always preserves aspect ratio
2) Ignore/break aspect ratio
- There was no clear consensus between the two options.
- A few people felt that the problem is created by putting sizing
in an alignment property and there should be thought on
avoiding that.
- The interested parties will talk over github and maybe get on a
call to keep thinking through the implications of these issues.
Relative URL resolution in var() references
-------------------------------------------
- There were two views on this issue:
- This is an edge case and an exception shouldn't be made as
it's harder to teach exceptions
- This problem makes URL in variables close to useless and
therefore needs fixing
- Several vendors weren't giving options and TabAtkins, who had
strong options, wasn't on the call, so discussion will
continue on github and a resolution will be sought on next
week's call.
Propose to replace "'text-orientation: upright' to cause strong LTR"
with author notes how to do it
--------------------------------------------------------------------
- RESOLVED: Add a note along the lines of koji's example telling
authors how to work around the lack of correct
implementation.
- The section will remain as a MUST with a plan to argue it's an
edge case and shouldn't block a move to PR.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Dec/0036.html
Present:
Rachel Andrew (IRC only)
Rossen Atanassov
David Baron
Bert Bos
Dave Cramer
Alex Critchfield
Simon Fraser
Daniel Glazman
Tony Graham
Dael Jackson
Brian Kardell
Brad Kemper
Chris Lilley
Peter Linss
Michael Miller
Rachel Nabors
Anton Prowse
Matt Rakow
François Remy
Florian Rivoal
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Lea Verou
Greg Whitworth
Steve Zilles
Regrets:
Tantek Çelik
F2F updates and call schedule for 2016 holiday season
-----------------------------------------------------
Rossen: Let's get going.
Rossen: First do we have any additional items?
Rossen: Quick update and a call for people on the holidays.
Rossen: Seattle is confirmed to be in Seattle. We (MS) will be
hosting in our West Lake office.
Rossen: We've reserved another room in a building that's in
walking distance for one day of Houdini. For those of you
attending both and booking a hotel or room in that area-
it will work for both.
<ChrisL> I will likely not be able to attend due to a one-time
conflict.
Rossen: I've also have confirmation from Hiroshi-san that the
proposed Aprils dates are secured. We'll be at a
university.
<astearns> Keio
Rossen: It's in Keio University in Tokyo. Dates are 17-21 Apr.
Rossen: That is it about upcoming F2F.
Rossen: Other part was I wanted to get an idea of if we should
have phone calls when since holiday and vacation times are
coming up.
Rossen: How many meetings will we be able to complete by the end
of the year? I'm assuming next week is good.
<Bert> is available on 16th, but not on 22, nor on 6
Florian: I agree next week is good. One after prob. After that
it's over.
glazou: Yep.
<dbaron> I'll be away next week but could likely make following
meetings
<dauwhe> -1 for the rest of the year for me :)
Rossen: Can anyone make the meeting between the 25th and 1st?
<ChrisL> 28th seems unlikely
glazou: We usually cancel that.
Rossen: How about the week before?
glazou: I will not
<gregwhitworth> I won't
Florian: I would
<astearns> I can
Rossen: Okay, I see some I will not and some how can. Sounds like
21st is tentative for now. I'll send an e-mail to the
private list before the call and we'll go for that. 28th
is out for sure.
<Bert> is available on 14th, but not on 21, nor on 4 (sorry
off-by-two :-) )
Florian: First week of January?
Rossen: Great question.
Rossen: Do we usually have that one?
Rossen: Jan 4th. Is that one we can make?
<dauwhe> I'll be around Jan 4
<Florian> I'm neutral on Jan 4
astearns: Given we cancel after the F2F we may as well have the
4th.
Rossen: Good point. Week after the first is the F2F.
Rossen: For now we'll keep Jan 4. Keep an eye on the private list.
If we don't get enough people we'll cancel on the fly.
Future work of FXTF specs
-------------------------
Rossen: We did have...during TPAC we had an SVG WG meeting meant
to recharter the SVG WG.
Rossen: We scoped everything down to a subset of current SVG 2 as
the proposed charter.
Rossen: There were a number of specs between SVG and CSS as FXTF
and they're now out of scope for SVG.
Florian: Intentional or just an unfortunate side effect?
ChrisL: It was.
Rossen: Yes. I see it as both intentional and a side effect.
Rossen: It was intentional as the WG was having enough trouble
landing SVG and it was unfortunate because they were
having trouble focusing.
Rossen: All the specs in FXTF being worked on were being done by
the WG with the exception of web animations. Web
animations is also mostly Houdini & CSS.
Rossen: Reason I'm forcing the discussion is we have to take
ownership and designate editors. That's the level setting
of the discussion.
ChrisL: When we have a TF the work has to be in the scope for both
WG. When one WG moves it out of scope I don't believe we
have to do anything special. We move on and select new
editors as we have for other reasons on a spec.
<leaverou> +1 to ChrisL
Rossen: That's a great point. We need spec editors keeping track
of what's happening in the WG.
Rossen: For example what happened to bring this up is there were
issues in FXTF repo that were open for weeks and no one
noticed.
Rossen: The specs worked on by FXTF are very important and we
shouldn't lose track of those. We can bring them under CSS
Drafts and continue work there with appointing editors.
<ChrisL> +1 to moving to csswg-drafts repo, if the issues also
migrate
ChrisL: I agree to moving them to CSS repo if the issues move
with. I don't know if they do.
Rossen: Who is a github ninja and can answer that?
plinss: I don't know of any mechanism to move the issues. They
wouldn't automatically. There may be a process.
fantasai: Do we have to move them or can we leave them where they
are?
Rossen: No one is paying attention.
ChrisL: We can close and re-open manually.
<smfr> https://github-issue-mover.appspot.com
<gsnedders> yeah, there's no way to do it automatically except
through the public API recreating all of them
Rossen: Okay. What if we agree to attempt to move them under CSS
WG drafts for overall visibility and that would be it.
ChrisL: sgtm
Rossen: Objections?
Florian: It looks like a fair amount of busy work to move things
around. It's a problem no one is looking. I'm watching
both but I'm not paying attention to these specs. For me
moving would change nothing. It's not just me, but others
may be in my situation.
Rossen: It sounds like there's an issue mover smfr put in IRC.
Assuming we can move the specs and the issues it makes
sense to have all the work for one WG in one place unless
there's a good reason for it. The good reason was FXTF but
that reason no longer exists.
<Florian> if the move is low overhead, then no objection
ACTION Rossen figure out how to move the FXTF spec while
preserving issues
<trackbot> Created ACTION-805
plinss: Should we be careful to preserve history?
Rossen: Yes, let me look into it.
fantasai: I think history is very important. If you're concerned
about not having attention it's a matter of set your
filters. I'd rather we didn't disrupt the history. For
issue tracking we've only been using github for a short
period.
Florian: You can merge and preserve history.
<gsnedders> You just use git read-tree in general
Rossen: Without spending too much more time, we agreed let's look
into what it means to move everything carefully to keep
history and issues.
Rossen: More important was we need to take full ownership of these
specs.
Stretching image grid items in both dimensions
----------------------------------------------
fantasai: I think there's a bit more to think about in general,
but one issue is if you have stretch in one direction
and center in another what is the size in the center
direction and does it account for aspect ratio. I
thought yes, Mats thought it was use original size in
direction not stretched.
fantasai: I think that will be confusing because that's not how
images every work. Any auto sizing that happens accounts
for change in the other side. Only exception is flexbox
where it would trigger a loop to get it 100% correct.
Everywhere else we maintain aspect ratio if you do any
auto sizing. That should stay true. We shouldn't
preserve real size against aspect ratio.
Florian: Makes sense.
fantasai: Other opinions?
<astearns> +1 for fantasai's position
<gsnedders> +1
fantasai: We need a resolution. Proposal is if an image is stretch
or normal in one axis it preserves aspect ratio in other
dimension unless explicitly overwritten.
fantasai: If it's stretch in both we break the aspect ratio. If
it's stretch in one dimension and center or something
like it in the other, that's the issue.
Rossen: How does that effect the sizing for things such as flex or
grid algorithm that depend on item size?
fantasai: I don't remember.
Rossen: If we only have one item and it is flex and it's an image
with stretch on the main and something else on the crop.
Would crop overflow?
fantasai: The image would take...let's say you sent a bunch of
prop and it flexes, in the cross axis if you spec center
it takes the size that would result from aspect ratio.
Rossen: Right. I wanted to make sure this is the part we're not
losing.
Rossen: Assuming that this is the case for the intrinsic sizing I
don't have a problem.
<jensimmons> https://github.com/w3c/csswg-drafts/issues/523#issuecomment-264106069
jensimmons: When I look at how Manuel described this issue I'm
confused. It sounds like the opposite of what he said
you're saying. Is the way he summarized accurate?
fantasai: Hang on.
fantasai: [checking]
fantasai: If we set stretch in both axis we break aspect ratio. If
it's stretch or normal in on axis and something like
center in the other that axis gets resized to match
stretch in the aspect ratio.
fantasai: So if you stretch 2x the center would also be doubled.
This is all for auto sizing. For auto sizing we preserve
aspect ratio in pretty much all but stretch stretch.
jensimmons: And Mats is saying if you do stretch in one dimension
it breaks aspect ratio. I think I'm leaning toward
what he's saying.
Rossen: I think you're agreeing to preserve aspect ratio when not
stretched.
jensimmons: No, opposite.
Rossen: Do you like option 1 or 2?
jensimmons: 2.
Rossen: Which is ignore the ratio.
fantasai: This is a case where you have an image that's 50x50. You
put it into 100x100 cell. You stretch one axis. It'll be
100 in one axis and stay 50 in the other.
jensimmons: I think that's okay. If you start to do stretch and it
get squashed you realize you should do stretch,
stretch. If the cell changes ratio the image would
too. If it starts normal, normal I want it to only
stretch where I change normal to stretch.
Rossen: And that's the overflow I was pointing out and according
to fantasai that shouldn't overflow.
fantasai: The flex will overflow. If you flex one it'll overflow.
Rossen: That's my assumption and it makes more sense to me...
fantasai: Especially if you have an auto size grid. I don't see an
image where you'd want to not preserve aspect ratio.
jensimmons: Why not normal?
fantasai: hang on, dbaron is on the queue.
dbaron: I'm confused with 100x100 grid cell since I understand
image size can influence grid cell size.
fantasai: Yes
dbaron: If an image is stretch in one dimension and you're
proposing to maintain the aspect ratio does the images new
size in the other dimension influence the grid size?
fantasai: That's a good question. Prior to a resolution 2 months
ago, stretch was the initial default. We're putting
sizing behavior in an alignment property.
fantasai: Normal should be equivalent to one or the other value.
Whichever can vary depending on element type, but we're
creating a system where we're sizing in an alignment
property and that's a problem. I'm unhappy with how
that's turned out so far.
Rossen: In the previous layout systems alignment didn't influence
sizing.
fantasai: Right.
Rossen: And I don't see why this should be a percent to change
flex or grid would would imply that option 2 would be from
a layout pov more predictable.
fantasai: I think there's more to think about here in terms of
trying to resolve. I'm against having multiple values of
alignment property effect sizing. We already have
stretch vs others. We shouldn't do more. We tried to do
that and it's creating a mess.
fantasai: I think this whole things needs cleanup and I don't 100%
know what that is.
Rossen: It doesn't sound like we can or want to resolve on this.
Rossen: Should we decide to work on this in a smaller group over
github or get on a phone if needed and go from there?
fantasai: I'm happy to do that. This week is finals, so I can't do
a lot for the next week.
Rossen: You take care of your finals and we'll figure out grid in
the meantime.
<jensimmons> I’m happy to get on a call about this all
<rachelandrew> I'd be happy to get on a call once I'm back (so
next week)
Relative URL resolution in var() references
-------------------------------------------
fremy: The issue is...basic premise of variables if you can define
them. I think there's an issue preventing this. If you have
a URL defining a var and it's not considered a URL until
replaced in a property. If you're using a relative
stylesheet it's not going to work. It breaks relative URLs
if you use them in variables.
fremy: I think it's user hostile. I proposed to remember the
origin of the URL token so you can resolve the URL later.
leaverou: I think it's a bit confusing to teach that it's defined
at time of use except this one case. Exceptions make it
hard to teach.
fremy: I'm not sure it's hard to teach. It isn't because it
doesn't have a meaning. The issue is you can't use relative
URLs if you want to use CSS variables. It's a big
limitation.
leaverou: So themes are hot linked? I think most authors download
them and use them alongside their CSS.
fremy: Probably not the same folder...every team has their own
folder. If you download you have to fix them. You can't use
relative URLs. I think that defeats the purpose of URLs. I
think we could make it not work until you define types with
customer property but I think that's worse because it'll
not work if you don't define the property.
fremy: afaict you can't define things like background and you'd
have to define background somewhere else.
leaverou: We should clarify this is quite an edge case. In most
cases people have a CSS folder. I think TabAtkins got
the right idea where URL tokens shouldn't be defined and
if they need to be we can use a declarative syntax.
Perhaps we could have a switch in the @ rule about how
URLs resolve so people could do either
leaverou: I think for now it's more important to be consistent
with CSS variables.
<astearns> +1 to making things work consistently for now, and
getting this case to work with typed variables in the
future
fremy: If it's just me maybe we shouldn't. Do other people think
this could be an issue?
leaverou: We could straw poll.
Rossen: TabAtkins isn't on and he had a strong opinion. I'm not
hearing anything from Mozilla or Webkit. I want to hear
more from other implement with their thoughts.
dbaron: I think it's easier to be consistent then try and add a
new mechanism. It's hard for me to say importance. I'm
somewhat swayed by the argument there will be other ways
to solve it.
leaverou: From what I've heard from Google the fremy proposal is
harder because you have to keep the origin of the URL
token along with it.
<dbaron> for us, it's actually a bit harder than that
Rossen: Hard may not be the same for everyone else. That's why I
want to hear more from Mozilla and Webkit.
smfr: Webkit switched to use Blink's CSS parser so we're much
closer on that.
ChrisL: It's arguable by design that these are untyped by design.
Though it's awkward for users it's consistent and we're
not building into a corner. I like TabAtkins declarative
syntax as well.
leaverou: I think idea with most Houdini API is we'll have
declarative ways eventually
ChrisL: Yes, but I'm hoping for a concrete proposal instead of
hoping for future
leaverou: Me too.
* fantasai isn't following variables too closely, but leaverou's
argument makes sense to me
Rossen: If I can summarize, TabAtkins has proposed an opinion on
github. Sounds like Webkit has a similar implementation to
Blink so if the decision was taken to align for Blink it
should workfor Webkit.
smfr: We implemented variables separately from Blink
implementation.
smfr: Webkit shares the CSS parser, but it has its own variable
implementation.
Rossen: Okay, I take it partly back. It should work in terms of
parsing if we align to blink.
<smfr> hyatt agrees with tab
Rossen: Also, dbaron said he's mostly persuaded by TabAtkins
proposal on github but not strongly opinion.
<dbaron> not sure where I said that...?
Rossen: Not much consensus with fremy on the other side.
Rossen: We can give this another week and with more impl can give
feedback on what the outcome should be rather then force a
resolution?
Rossen: What do you think? We can try and force consensus.
ChrisL: If we can get resolution it would be good because we're
missing some testing in that area
leaverou: I think we can wait a week. It's important TabAtkins
weighs in.
fremy: Yeah, okay.
Rossen: This is now on the radar of everyone that should be
interested. We'll discuss it in a week. Before them people
can go on github and bring other data points.
Propose to replace "'text-orientation: upright' to cause strong LTR"
with author notes how to do it
--------------------------------------------------------------------
<dauwhe> https://github.com/w3c/csswg-drafts/issues/755
Rossen: This was from koji with comments from Florian.
koji: This is something we discussed in TPAC. I have new
information pieces. First, there is a way for authors to
make it happen using bidi and direction properties.
koji: It's in the last comment, but this is whether to make it
automatic.
koji: Other thing is I think I said no browsers have implemented.
Gecko has partial implementation.
Rossen: Did you check Edge?
koji: The test fails. I'm not sure...
Rossen: We're unprefixing upright
koji: This is text orientation
Rossen: Perhaps I misspoke. Sorry.
koji: I'm okay to leave as-is since Chris says it can be
exceptions. By understanding it's doable by authors it might
be better to use notes saying author can do it.
Florian: On the work around, if a browser implemented according to
spec and an author also applied to work around it would
be okay. Implement and work around don't conflict.
Correct?
koji: The complex...I need to think.
koji: It's not easy to answer from the top of my head. Text is
only one line but it's quick complex. Descendants could have
different bidi and in those cases it's complicated.
fantasai: We try to avoid having authors touch the unicode bidi.
It's mentioned the authors shouldn't normally do this.
koji: I put we could recommend bdo instead of properties.
fantasai: It's not correct to do that. If you have your markup you
don't want to change that based on stying. Cases to do
this are very stylistic. You want something to look like
a book spine.
fantasai: You might decide later you want it horizontal or you
have fallback code where you can do transforms if you
don't support writing modes. You can't do that if you're
setting bidi codes in the page.
fantasai: The bidi stuff is a content thing. It doesn't belong in
the style layer and needs to be separate.
koji: But requires ltr is stying.
fantasai: Vertical upright requires the typeset to ltr because
when they're upright they'll be left to right in the
typesetting POV. Doesn't mean it's rtl text in general.
If you change the writing mode so it's sideways it needs
to honor it's intended directionality.
fantasai: We don't want authors using direction in bidi, but in
the markup is worse.
<dauwhe> Note that I emailed this issue to the EPUB WG on Monday,
and didn't get any feedback.
Florian: I don't think fixing the markup is good, but we have to
choose between few bad options. This is a relatively rare
case. Holding the spec up on a rare case might not be
great and asking browsers to fix this rare case isn't
great. If we can go to rec and not and exception I think
that would be fine.
Florian: If we drop to a should and restore to must that might
work. That's why I asked if the work around works if a
browser impl. If that's the case we can say this is a
should and if the browsers don't impl here's a work
around.
fantasai: That seems like a better way forward
fantasai: The work around is not compat without an impl that
supports text orientation upright.
Florian: But you can use @supports
fantasai: Yeah. That should go in the example.
Rossen: I agree this is a corner case and hanging the spec on this
isn't a great idea. From the options listed, what do we
feel we can resolve on?
Rossen: 1) we can mark as at-risk 2) mark as should 3) and a
non-normative example of the work around. or a combo of
those
Florian: I was suggesting a combo. I think we should introduce a
note. The choice is drop to a should or keep as a must
and argue during the call we should still go to rec.
Rossen: Koji?
koji: I'm okay with any.
Florian: I think it goes to what will be easier. If the "it's a
must but we don't care" is easy let's do that. if it's
problematic we should drop to a should.
Rossen: Can you summarize a proposed resolution?
Florian: Add a note along the lines of koji's example telling
authors how to work around the lack of correct impl.
Rossen: I don't think we need a resolution on a note.
Florian: It's in CR.
Rossen: Correct. Sorry. Objections?
RESOLVED: Add a note along the lines of koji's example telling
authors how to work around the lack of correct impl.
Florian: Either we don't need a second resolution and leave it as
a must, or if we're worried we can drop to a should and
restore to must at next level.
Rossen: Doesn't sound like we need to resolve on this now. We can
make the must as a should during CR.
koji: I'm okay with it.
<glazou> +1
Rossen: Can we live with this one resolution for the note and
react later if needed?
koji: I'm fine.
Florian: Think so.
Rossen: Let's call this closed and bring this back if needed
during PR transition. We'll talk next week.
Received on Wednesday, 7 December 2016 20:25:33 UTC