- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 18 Jun 2015 07:48:13 -0400
- To: www-style@w3.org
transform-origin UA style
-------------------------
- RESOLVED: Adopt second suggestion from Cameron
(https://lists.w3.org/Archives/Public/www-style/2015Jun/0109.html)
about the UA style sheet plus a note saying initial
transform-origin for SVG elements won't lead to an
expected result.
Percent resolution for abspos vs in-flow grid items
----------------------------------------------------
- All the needed parties weren't available to reach a formal
resolution, but the group leaned toward deciding that grid
items are treated the same way always for percent resolution
regardless of how they got to be laid out.
Grid Issues
-----------
- RESOLVED: normal computes to 0 on multi-col on grid containers
- RESOLVED: grid-gap property is the shorthand for column-gap and
row-gap. grid-gap resets both.
- fantasai will create a note for grid and flexbox about authoring
tools supporting the must requirement to re-order the DOM in a
logical way. Once that is complete the group will resolve on
adding it.
- A decision on percentage padding/margin for abspos boxes with
grid container containing block will wait until dbaron returns
in July.
CSS 3 UI
--------
- RESOLVED: Update the REC for css-style-attr
- The chairs will talk to plh to see if there is any flexibility
in the publication process before the group spends time
deciding if they want to change how they handle publication.
- box-sizing will still be removed from level 3. If there's a
strong use case for it, it can be added to level 4.
- A decision on if the UA may treat unsupported values as auto will
wait until tantek has a chance to weigh in on the issue.
Elements and Nested Scrollers
-----------------------------
- Discussion will continue on the mailing list now that awareness
is raised.
===== Full Minutes Below ======
Present:
Rossen Atanassov
Adenilson Cavalcanti
Bo Campbell
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Koji Ishii
Dael Jackson
Brad Kemper
Peter Linss
Edward O'Connor
Matt Rakow
Florian Rivoal
Simon Sapin
Alan Stearns
Regrets:
Tab Atkins
David Baron
Sanja Bonic
Chris Lilley
Mike Miller
Anton Prowse
Takayuki Tsukitani
Lea Verou
Ian Vollick
Steve Zilles
scribe: dael
glazou: Let's get started.
glazou: Anything to add to the agenda?
transform-origin UA style
=========================
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Jun/0109.html
glazou: I'll handle this one since krit isn't here. There is a
tentative explanation of the issue for default transform-
origin for SVG elements.
glazou: There is a problem between svg and non-svg which is 0,0
for svg and 50%,50% for others.
glazou: There is a decoration that would do the switch, or a
proposal from Cameron that would change the default style
sheet.
glazou: krit is handling it and he has a slight preference for the
option from Cameron.
glazou: What do people think about this?
* fantasai thinks Cameron's suggestion makes sense
Rossen: I was at the svg F2F last week. The one issue that we
discussed during that topic was if we don't have the
'auto' value, what happens when you set to 'initial'.
Rossen: The UA style sheet will get up and running the first time
and when you reset the transform-origin to initial, we are
screwed.
glazou: That's a good point.
Rossen: My preference was to go with 'auto' even though I don't
like automagic defaults, but it will cover that use case
which I believe is important.
<Florian> The stylesheet approach might have been fine if there
was no compat concern, but there is, so auto.
glazou: But we have the value anyway so it must work in all cases.
glazou: I was more in favor of the second proposal, but that's a
very good point.
fantasai: The initial keyword computes to 0,0?
glazou: It computed to 50%,50% on svg elements.
fantasai: Does anyone use 'initial' on transform-origins?
Rossen: I'm assuming they do.
fantasai: It's fairly obscure. If you know it takes a position
you'll put a position into it.
Rossen: Working for the last 12 months on interop, 'initial' is
used a lot.
glazou: And if it's available to all CSS properties, we need to
make it available. It's a question of being consistent.
smfr: CSS resets, do they set value to initial?
Rossen: They're supposed to.
fantasai: The concern is web compat. Cameron says FF and Webkit
already impl it. They're evidently not hitting a problem.
Rossen: My point was for consistency. That they're not running
into issue today, let's say in a year SVG gets more
traction, the initial value is well defined and people are
using it. If they do it for transform-origin they will get
unexpected results.
fantasai: They will get an unexpected default if they use it on
anything that the UA sets a different default and we do
that on a lot of things. We do that where we think
initial is one thing but somewhere we set it to
something else because that's the important default.
There's no need for this to be more complicated.
hober: I agree.
glazou: I have a problem with that point of view. We have two
requirements. First is, it's a constant of CSS spec. We
need to solve the 50%,50% instead of 0,0. The second is to
make sure initial works correctly.
glazou: The question is, does the first proposal or second
proposal solve both requirements. It seems the second is
not. That's my personal opinion. It seems the first one
could fix it at the cost of some change in browser impl.
Florian: If we had no compat issue to worry about, both solutions
could be reasonably used. We are using UA style sheet for
a bunch of things so there are a bunch of things where
you get a different value from initial. It means it's
okay to do. But since it was brought up that doing it
with the UA style sheet is done, doing else wise would be
compat issue.
<fantasai> I would like to also smash the idea that the initial
value of every CSS property needs to be 'auto' if we
would otherwise need a UA style rule to get the right
behavior. We don't do that anywhere else.
<fantasai> If we can represent the UA stylesheet without 'auto',
we don't add 'auto'.
<Florian> +1 to fantasai
glazou: Since we don't have krit, I told him I'd issue a call for
consensus.
Rossen: Just because we don't have krit doesn't mean there aren't
other SVG members.
Rossen: If we can get close to a resolution I would prefer that.
Rossen: I wanted to bring up, to contradict myself in proposing
auto, it will bring the auto for animation and position
kind of iffy because we'll have to allow transform-origin
to be animate-able.
Rossen: We can argue both ways quite a bit. I would be okay with
the second proposal, but we have to be clear that we are
going against what initial is supposed to do. Or at least
if people start using initial they might get unexpected
results.
glazou: You're suggesting the second proposal with a note?
Rossen: I'm not opposed, yes.
glazou: Second is the UA style sheet with a note about the danger
of using initial on svg elements.
<fantasai> We just made applied this exact principle to cursors:
minimizing the automagic in favor of using the UA style
sheet. I don't understand why we are arguing in the
opposite direction here.
Florian: I would prefer that. Also because what fantasai put on
IRC.
glazou: fantasai you agree?
glazou: The UA style sheet plus a note saying initial
transform-origin for SVG elements won't lead to an
expected result.
fantasai: Yes, a note or example would be helpful. It's a good
idea.
glazou: Objections?
RESOLVED: Adopt second suggestion from Cameron about the UA style
sheet plus a note saying initial transform-origin for
SVG elements won't lead to an expected result.
<glazou> ACTION glazou: email krit about resolution item 1
<trackbot> Created ACTION-694
percent resolution for abspos vs in-flow grid items
===================================================
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015AprJun/0164.html
glazou: That's from fantasai.
fantasai: I don't have a clear thought, but I'll present.
fantasai: We discussed percent resolution in the block dimension
for flexbox and in-grid items. What Mats pointed out is
if you have and abspos grid item which we can do, those
margins because it's abspos will have vertical resolve
against horizontal.
fantasai: So if you position an item in a grid area, if the
margins are resolved against horizontal or vertical will
depend on if it's abspos. That's pretty inconsistent, so
do we want that situation or do we change abspos or
grid.
Rossen: In our implementation of grid, grid items are treated the
same way always for percent resolution regardless of how
they got to be laid out.
Rossen: If an abspos element makes its way from the first level
children of grid or somewhere deeper inside of the element
chain it shouldn't matter. It's still part of the grid and
will be laid out for all grid rules and this shouldn't be
an exception.
Rossen: If we're allowing you to, for ex position and abspos item
in a grid row/column, there's not reason for it not to
resolve % the same way as other grid items. Same for flex.
fantasai: Okay.
fantasai: We're missing dbaron and TabAtkins so I don't think we
should resolve, but if anyone has something to add to
think about it, let's do that.
Florian: I'm confused about the statement of same for flex. You
don't abspos something into flex, do you?
fantasai: No.
Florian: You have something that would be flex but you abspos it
away from flex?
Rossen: I missed that.
Florian: I was saying that in the flexbox case, if you have a flex
item you abspos to someplace else it's ancestry is in the
flex, but it's not a part of the flex box.
Rossen: What I said is that the use case from Florian is correct,
but it's the opposite of what we're talking about. He said
we have a first child of a flex box that's abspos, but the
flexbox isn't abspos. In that case the abspos flexbox item
will be laid out and processed whereever it gets processed.
Rossen: So what we were discussing is the opposite where a deeply
nested element is abspos but also gets its position
container to be grid or flex and that grid of flex is
doing layout for the abspos item. SO the rules for that
grid or flexbos should apply.
Florian: That makes sense to me, yes.
Rossen: I just wanted to point out that there should be no
difference between flex and grid.
Florian: I think what IE currently does makes sense, but we should
defer for other people.
glazou: If there's nothing more to say, let's move on.
Grid Issues
===========
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015AprJun/0166.html
row/column gap
--------------
glazou: That was from fantasai with two items. First is row/column
gap issues, second is a11y.
fantasai: There's three parts of row/column gap. First is should
normal value of row-gap compute to 0.
fantasai: There is supposed to be interpreted as a UA value in
multicol, I think it's easier to authors to compute to 0
on grid containers. The list seems to agree, but I think
we should resolve that normal computes to 0 on grid
containers.
Rossen: I'm having a hard time getting to the e-mail.
fantasai: gregwhitworth agrees.
fantasai: So it should be okay.
fantasai: gregwhitworth replied to the list that it makes sense so
I'm assuming it makes sense for Microsoft in general.
Rossen: gregwhitworth has opinions, but I have some too.
glazou: Objections?
RESOLVED: normal computes to 0 on multi-col on grid containers
fantasai: This is for row-gap and column-gap. We want to have a
short hand. Options are grid-gap and track-gap, but I'm
open to other suggestions.
<astearns> grid-gap sounds ok to me
Rossen: grid-gap sounds good.
hober: It's also consistent. track-gap would be confusing about
not applying to multi-col.
fantasai: It does apply in multi-col because it's a short hand
that sets row and column gap.
hober: If it applies in multi-col I'd say track-gap sounds better
because it doesn't rely on another mode(?)
<Florian> +1 to hober
fantasai: Track is a grid layout term, but not for rows and
columns. Not sure that it makes it better.
Rossen: Yep, I agree with fantasai that track isn't applicable to
multi-col.
<Florian> gap
Florian: Do we have a plan to add another property that's a better
use for the word gap alone?
fantasai: I don't know.
fantasai: We might want to look at the next issue to help decide.
Should the shorthand reset the gap property?
Florian: Based on this it seems the text should be probably not a
good idea for gap. We can just call it grid-gap for the
general property.
fantasai: I think having the grid shorthand reset the gap property
is a useful thing. The interaction with multi-col isn't
a problem because you can't have an interaction. It's
only column-gap that applies the multi-col. It's
unlikely people would try and combine multi-col and grid
because they do very different things.
hober: So you argue people will only want to use the shorthand
when doing grid layout so we can name it after grid. That
seems reasonable.
Rossen: Did we consider something like gutter?
Rossen: It doesn't say gap in the name, but it describes the gap
in all those layout types.
fantasai: We can't use gutter without a prefix since that's
confusing with the page gutter, which is the part of the
page used for binding. If we have a row-gap and column-
gap, the shorthand should be gap not gutter.
Rossen: I'm fine with it. We can change it later.
<Florian> gutter -> row-gutter column-gutter
<SimonSapin> +1 fantasai
RESOLVED: grid-gap property is the shorthand for colum-gap and
row-gap. grid-gap resets both.
a11y, tools, and reordering
---------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Jun/0180.html
fantasai: Basically, we have a requirement that authors shouldn't
use grid or flexbox reordering to reorder the source
differently than the visual order when it's not
beneficial for a11y reasons. When you're reordering you
do it in the source. We want to add a conformance
requirement on authoring tools where if they don't
change the source, that's the opt-in for the author.
fantasai: It would be non-conformant to have an authoring tool
that lets you reorder items in grid just by changing
grid properties unless the author using the tool says I
don't want you to reorder the source.
glazou: What do people think?
bo: Can you describe what an author opt-in means? I'm not sure I
understand.
fantasai: The default behavior of any authoring tool that allows
re-ordering using grid or flexbox, it does the re-
ordering by re-ordering the source, unless the author
specifically says I want to keep the source order the
same. The default behavior without the author doing
something to choose visual re-ordering only, would be to
change the source order.
Rossen: I guess...this is a requirement that we will take. Having
ordering and the ability to re-order items in those
layouts is both useful and very appropriate to be done on
the CSS layout. For example, you want to re-order images
backwards to show the oldest first. I don't see why you
would re-order your entire file. I see the a11y, but I
find it difficult to believe it would be done anywhere
except the CSS layer if you can do it there.
Florian: I'm not convinced this would make a huge difference on
what people do, but I agree with the requirement.
hober: I am worried that the requirement makes assumptions about
the UI of authoring tools that might not match a
sufficiently new authoring tool UI. I don't want this rule
to restrict authoring tool makers from innovating new ways
to present these features, but on a meta level I don't make
an authoring tool so I'd like to hear from people that make
authoring tools. Do they find it reasonable. glazou is the
only person we have that makes an authoring tool.
glazou: I have no opinion yet because I haven't dove into flexbox
or grid for my authoring tool.
Rossen: The tool makers on our side, I don't believe these guys
look into this kind of requirement closely.
Florian: Yeah, I think it does not matter what we write it might
not be applied, but they indicate intention.
hober: I think that suggests it should be a note as to the best
practice instead of conformance.
Florian: We have that.
fantasai: I don't think we do.
Florian: On authors, not tools.
fantasai: We have a conformance requirement on authors to order
their DOMs in a logical way.
glazou: In the W3C sheet there is an a11y guidelines post and it's
the best post out there.
Florian: Given that we have an author requirement, we can have a
note to the authoring tools saying their UI should take
this into account.
glazou: I'd like us to warn the people editing the doc to know
about it.
Florian: In addition to, yes.
glazou: A note in the whole spec while the document is about
authoring tools entirely.
Florian: Having the note in both places, yes.
fantasai: I think that makes sense. I'm happy to draft text for
that.
<SimonSapin> "must" in a note?
glazou: SimonSapin has a good question.
Florian: It's a note explaining to authoring tools that authors
have a must. It's an explanation of a must.
SimonSapin: Ok, fair enough.
glazou: Let's defer until fantasai makes the text. Do you accept
an action to write it?
fantasai: Adding a note to grid and flexbox and add a note that
they can add conformance criteria if they wish.
bo: This feels like a stop-gap about the bigger a11y issue for
flexbox. This brings awareness to it, it does help.
ACTION fantasai to write a note about authoring tools supporting
the must requirement to re-order the DOM in a logical way
<trackbot> Created ACTION-695
percentage padding/margin for abspos boxes with grid container
containing block
---------------------------------------------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015May/0154.html
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015AprJun/0168.html
gregwhitworth: We had the same issue with interop about fixed
position. However we get CSS 2.2 update we need to
be able to say fixed position if Gecko changes, it
seemed like we're leaning in that direction.
gregwhitworth: I don't know if this needs much discussion unless
Gecko disagrees.
glazou: We don't have dbaron. So that defers until early July.
gregwhitworth: I don't think I need to be here. However we get it
updated, we just need to know if he disagrees.
Rossen: We have implementation intent from Blink.
gregwhiteworth: No, blink and webkit have it.
CSS 3 UI Issues
===============
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015AprJun/0165.html
Updated REC for css-style-attr
------------------------------
glazou: Let's do the two last ones about publication.
Florian: There was a minor issue, it doesn't change anything, a
term was just defined twice and it was causing errors.
glazou: No object?
RESOLVED: Update the REC for css-style-attr
glazou: Do we have Bert?
fantasai: I can work with plh to publish.
Publication Requirements
------------------------
Florian: We don't have TabAtkins for the other one. There was an
issue he raised where he realized that our publication
practice wasn't a w3c requirement, but a CSS WG rule and
he wanted to change publication to let authors deal with
it.
fantasai: I know I've published directly to web-req, but they
wanted me to talk to the staff contacts. Given staff
contacts aren't here...
glazou: These are things chairs need to discuss with plh and
web-req. If you want us to discuss we can.
Florian: I think it's an action on the chairs to find out if it's
possible to see if it's worth discussing.
glazou: Let me ping plh on if it's possible and I'll get back.
Elements and Nested Scrollers
=============================
glazou: One question, smfr are you on?
smfr: yes.
glazou: Did you want to talk about item 9?
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Jun/0147.html
smfr: We're making progress on the ML, but I wanted to ask
Microsoft for feedback.
MaRakow: I saw the mail, but haven't gotten to digest.
smfr: There was another only about containing block that would be
good to nail down.
CSS 3 UI
========
box-sizing
----------
Florian: I'd like to mention something about CSS 3 UI. Our "LC"
period ends today. We have a handful of small issues open.
There's maybe one or two we can tackle on the call. I
don't think we can go to CR.
Florian: During the F2F we thought we might drop the box-sizing
and Mozilla was going to figure out if it was okay, but
they removed it from their code base.
fantasai: There was a resolution on the Wednesday minutes to drop.
Florian: Okay. So we do drop it. I had a discussion with authors
that it was nice, but not with any major use case. In
some cases it's convenient, but it can be done without.
If vendors agree we should remove, we stick by the
previous resolution.
fantasai: If there's strong demand it shows up in level 4.
Florian: Okay.
Cursor treating unsupported values as auto
-----------------------------------
Florian: The other thing is the CSS3 UI spec talking about the
cursor property it has supposed values as auto.
glazou: URL?
<Florian> http://www.w3.org/mid/DB2A75EC-6C11-44A7-A043-4A2418ADC3C9@rivoal.net
<Florian> The UA may treat unsupported values as auto.
<Florian> E.g. on platforms that do not have a concept
<Florian> of a context-menu cursor, the UA may render
<Florian> default or whatever is appropriate.
Florian: [reads text]
Florian: I don't think this is good, if you don't support, don't
support and people can use a test page. "do whatever is
appropriate" is vague.
glazou: Is tantek on the call? I'd like to hear the original
reason for it.
glazou: I tend to agree, but I'd like to hear from him.
Florian: That's reasonable.
glazou: Okay, ping tantek to give us context.
* fantasai and please compile a DoC
ACTION Florian ping tantek for reason the UA may treat unsupported
values as auto.
<trackbot> Created ACTION-696
glazou: I suggest we stop here. Thank you everyone. Bye.
Received on Thursday, 18 June 2015 11:48:42 UTC