- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 2 Mar 2016 19:33:12 -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.
=========================================
CSS Snap Size
-------------
- Several people have requested more time to review before
resolving on FPWD.
- Any questions will be discussed on the mailing list and, if the
issues are resolved, the group will revisit in two weeks.
Layout containment and overflow
-------------------------------
- RESOLVED: Accept #3 from the e-mail (Overflow is allowed
visually, but it doesn't project its "geometry" past
the layout-contained ancestor, so it can't trigger
overflow past a layout-containment boundary) and say
hit testing is currently undefined.
- RESOLVED: Mark the undefined hit testing as an issue.
Styling the disclosure triangle of the <details> element
--------------------------------------------------------
- TabAtkins informed the working group that a decision was made by
WHATWG to call <summary> element a display list item and the
disclosure is a list item.
- There was some strong objections to this decision; it was felt
to be unfriendly to authors.
- Anyone who objects should contact WHATWG as it was their
decision.
grid-template shorthand
-----------------------
- RESOLVED: Remove the grid-template shorthand and fold it into
the grid shorthand.
Events for FontFaceSet
----------------------
- TabAtkins will reach out to the appropriate implementors to
continue conversation on this topic.
CSS OM
------
- The publication resolved on during Sapporo will happen soon.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Mar/0025.html
Present:
Rossen Atanassov
Tab Atkins
Bert Bos
Dave Cramer
Greg Davis
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Koji Ishii
Dael Jackson
Brian Kardell
Chris Lilley
Peter Linss
Michael Miller
Simon Pieters
Anton Prowse
Matt Rakow
François Remy
Florian Rivoal
Hiroshi Sakakibara
Alan Stearns
Lea Verou
Greg Whitworth
Steve Zilles
Regrets:
David Baron
Tantek Çelik
Alex Critchfield
Scribe: dael
May F2F
-------
Rossen: Let's get going
Rossen: I wanted to give an update of where we are. As you know
the dates are firm and Shane and Ojan from Google have
been working to secure a room for us in their San
Francisco office. Current situation is there is a room
secured and reserved for us. Problem is the current
capacity is about 30 people.
<glazou> dates and precise location?
Rossen: The actual...I'll paste into IRC
Rossen: It has [reads]
<Rossen> room's large enough for 56 (standing) / 48 (theatre) / 22
(classroom) / 30 (clusters), and is 690 sq ft (about 8m x
8m).
Rossen: So the room is not huge. I was going over past attendance
of F2F and if we are considering members only we should be
able to fit.
Rossen: If we don't think we can fit or be comfortable there for
all 5 days of CSS and Houdini, shout out and we'll see if
we can get something else. Current state of room booking,
this is what we have.
<bradk> I can probably attend this one, since in Bay Area
glazou: One thing that has been consistent is that attendance to
meetings in San Francisco is higher than others. I'm
wondering if it's enough.
Rossen: Yeah. That's why I said if it comes to it, we can limit
the meeting to members only and if there are people who
want to observe, as long as we're under 25 we'll be fine.
glazou: My point is that we're usually 30-35 members in San
Francisco not counting observers. Some people who never
show up show up there.
Rossen: If you believe it's going to be the case...
glazou: It could happen. If it has to be that room I suggest a
poll as soon as possible. It could be a harsh limit.
Rossen: We could do that. I'll send an e-mail to the members list
and the Houdini one.
Rossen: I was looking at last couple years and even Santa Clara we
weren't that much for members. We had a lot of observers.
* glazou said SanFran, not Santa Clara....
Rossen: This was the topic I wanted to bring up. If anyone has a
strong allergic reaction and believe we won't fit, send me
an e-mail or the e-mail list a message.
Rossen: Shane and Ojan haven't stopped looking for something bigger.
Rossen: And the dates are May 9-11
Rossen: 12 and 13 for Houdini
Rossen: Basically 9-13 for those joining both.
<Rossen> May, 2016-05-09..11 (with possible Houdini 12-13), US
West Coast
Rossen: Any questions or anything else on this topic?
CSS Snap Size
-------------
Rossen: Call for feedback and a request for FPWD.
koji: I uploaded the spec from the proposal I presented at last
F2F. Spec was changed a bit from proposal as I
experimentally implemented it and found some things.
koji: After that I think the current ED is in good shape.
koji: I appreciate reviews and feedback. If this looks good I'd
like to publish as FPWD.
Florian: I'm happy to see work on this area, but haven't had time
to review the draft. Would it be okay to ask for a week?
In general I'm okay, but I haven't had time to read what
you'd done.
* fantasai hasn't read the draft either
ChrisL: Are you likely to object? I'd rather make the decision to
publish now and if you decide you want a change just shout.
fantasai: I think that works well when we have a draft, but for
FPWD we want to make sure everyone agrees that this is
something we potentially want to implement. It's not a
request as to if this is an improvement, but a question
as to if we want to pursue this. For that reason, I
think it's important to have a more positive consensus
and not just a "sure, why not".
Rossen: Fair point.
Florian: If 2 weeks are possible, I'd be delighted, but if we want
one week I can try.
* fantasai would prefer more time as well
Rossen: So we have one member asking for an extension on the
decision.
astearns: I still have the feedback I gave in Sydney. The draft as
stands doesn't talk about snapping, just modifying
heights in inline boxes. I'd prefer terminology that
doesn't use snap.
astearns: Bigger concern is this is only inline boxes and not
block boxes. That's a terrible mistake. We shouldn't
design a feature that gives you this height manipulation
and restrict it to inline. For example... 2.3 has an
example I think is terrible. I'd object to having a
draft that says this doesn't apply to block level.
koji: The feature...The first point I'm not sure how better to say
it than snap. I think you meant not to grid. It snaps size,
not position, to a specified value. If you have better
terminology, I'm fine with that.
astearns: I'll try and come up with something.
koji: For block level, from and implementor's point of view making
block snappable adds quite a lot of complexity. This has
been discussed a long time without being implemented. I'd
like small parts to step and we can add features later.
astearns: You've been doing an experimental implementation. Have
you heard interest from other implementors to try this?
koji: It's generally hard.
Florian: I think that's one of the difficulties with this. The
reduced version is simpler and therefore more likely to
implement. Same time it does less than other things we
discussed before. If we can get this and not the rest
that's an up side, but if you can extend in the different
direction as astearns suggests you get more. It's close
the grid snapping and close to general sizing problems.
It covers both problems spaces a bit but not completely.
Florian: That's part of why I want time to review.
Florian: To see if we need to extend to properly solve this.
* fantasai shares Florian and astearns' concerns; hasn't looked
too deeply into the specific technical details.
Rossen: So we need more time to work on this before we go to FPWD.
astearns has some feedback that hasn't been fully
addressed. Florian may have feedback and some potential
interest as well. How about we give it 2 weeks and work on
the mailing list.
Rossen: We will revisit the decision in 2 weeks if we agree on the
mailing list this is ready to go.
Rossen: How does that sound koji?
koji: Sounds great, thank you
Layout containment and overflow
-------------------------------
<Rossen> https://lists.w3.org/Archives/Public/www-style/2016Feb/0314.html
Florian: That's TabAtkins and me.
TabAtkins: A few weeks ago we talked about what to do about a
layout contained element that overflows. It naively
allows overflow that allows scroll and violates
existing semantics.
TabAtkins: I was actioned to talk to our implementor. By accident
we're doing solution 3 in the e-mail: when children of
a layout contained element overflow, the ancestors
don't know about it. So they cannot trigger scrollbars.
They will overflow visually in the worst case.
TabAtkins: I went ahead and specced that.
TabAtkins: The only remaining question is if the overflowing part
should be able to hit test.
Florian: I believe the behavior TabAtkins described is called ink
overflow. I agree this is the behavior we want, we just
disagree on if it's called that.
TabAtkins: Ink overflow is the right term. I'll switch the spec to
use that.
smfr: Ink overflow becomes visual overflow and the driver still
has to manage overflow and you may need some code to treat
it as ink overflow. That it works as a side effect we
shouldn't spec that way.
TabAtkins: I think it's a nice benefit, but also #3 is the right
way.
smfr: #2 is the logical behavior you want and easy to implement.
TabAtkins: Why is that best? We have the concepts separated
because they're separate concepts.
smfr: It seems odd at some level to convert layout and ink overflow.
TabAtkins: Basically we just don't inform the ancestors that
there's any overflow happening.
TabAtkins: So the layout is the normal bounds.
Florian: That's paint time.
TabAtkins: The layout code that figures out if there's scroll bars
is not informed of the overflow.
smfr: I'm not too happy with that.
Rossen: It should be like the #3 for me...it sounds like you're
bubbling up the behavior of overflow on a child to its
containing scrollers. Once you have a child that has
overflow contain, it becomes ink only, the parent is not
supposed to be able to scroll to that ink overflow. I'm
concerned this will break a bunch of scenarios.
TabAtkins: This is only the contain property. It doesn't effect
scrolling, but things outside layout contained elements
doesn't see effects.
Rossen: You have one element which is a scroller, overflow: auto
and one div. This div is width and height 50% so it
doesn't cause scrollbars for scrolling parent. If you
insert a third element inside the div you're saying you
can't get to it if it's overflowing.
TabAtkins: If the middle element has contain:layout on it. You're
saying nothing in this element should effect layout
outside this element.
Rossen: How do you scroll to show the entire...you have the parent
which is a scroller, but no scroll bars trigger.
Florian: And you're explicitly asking for this not to change
regardless of the middle div because that's the point of
contain:layout
Rossen: You're creating a case where users can't see content.
TabAtkins: No more than paint containment already causes. I'm
saying on certain situations make assumptions.
contain:paint hides all overflow, no matter what.
contain:layout says that if you really overflow you
can't see it, but that's less worse than paint layout.
fantasai: Basically what this is doing is saying the element with
contain:paint the layout overflow is the size of the box.
The ink is whatever the union of ink and layout would
have been. It's not complex and digging around in
scrollers. Just for that element you clip the layout
overflow and left the ink to be as big as the rest of
the content.
TabAtkins: Yes.
<Rossen> <div style="overflow: auto; width: 100px; height: 100px:">
<div style="contain:layout; widht: 50%; height: 50%">
<div style="width: 200px; height: 200px;"> This will be
clipped</div></div></div>
smfr: I'm concerned about hit testing.
smfr: I don't think we take ink overflow into account with
hit testing. We may have to do work.
TabAtkins: If making it interactive is hard, we just don't do #3.
So the assumption is don't overflow your layout
containment you crazy person because you can't interact
with it. That's fine.
Rossen: This will be difficult to implement for us.
Florian: I think I'm still in favor of #3, but if we consider the
alternative of layout overflow implying paint overflow,
it's worse. If you do option 3 you can see them
sometimes, #2 you'll never see them. So it doesn't fix
that aspect of the problem.
TabAtkins: I was just making certain that shadows are ink overflow.
So we're saying layout:contain is the same as the shadow.
Florian: The only question is do we hit test
<fantasai> hit testing is only border-box area (as modified by
border-radius)
<gregwhitworth> hit testing on a shadow is much different than hit
testing on content
<fantasai> shadows are theoretically infinite :)
Rossen: Say layout overflow for contain:layout becomes ink. The
geometry isn't propagated up so no floats that are part of
that can penetrate.
TabAtkins: You're formating context, that's beyond definition.
This is only about scrollbars on ancestors.
Rossen: It sounds like you want to resolve on option 3
TabAtkins: So resolve on option 3, that's in the spec. And, if
possible, I'd like to agree on hit testing. Sounds like
we're leaning no on it.
smfr: I'm concerned about creating a foot-gun and they have ink
overflow and don't realize it.
<gregwhitworth> I agree, a lot of this feature feels like a foot
gun.
TabAtkins: This property at its basic is a foot gun.
Rossen: Invisible and not interactive is by design. Visible and
not interactive is a poor UX.
TabAtkins: That's why you don't do it. Contain isn't designed to
be a safe property.
<fantasai> +1 to smfr's point. It's much more confusing if it's
visible but not interactive--the author is much less
likely to notice the problem.
Florian: If you don't give an explicit size it will collapse to 0.
TabAtkins: There's a lot of things to discourage causal usage.
Rossen: There's a number of people concerned about the
non-interactivity.
TabAtkins: This property in all aspects creates bad behavior if
you don't treat it right. It's terrible to use if you
don't obey the restrictions. It's not safe. It's
'optimize me really hard'.
Florian: TabAtkins position was that he wanted hit testing and the
suggestion that it's hard from implementors is what is
causing us to say no hit testing. I'm for it if we want
hit testing.
Rossen: I still believe it will be tricky to get the hit testing
on our end.
Rossen: TabAtkins does your current implementation hit test?
TabAtkins: I don't know yet. Our implementor hasn't answered me yet.
Rossen: At the least if we go with option #3 and require it to be
hit testable per spec, would that be okay with other
implementors? Specifically smfr?
smfr: I have to think about it. I don't want to make it hard to
implement this property. The point is the browser can do
shortcuts to make it fast and if the browser has to do a lot
for hit testing that defeats the purpose.
TabAtkins: Just the scrollbar question, I said this is easy for us
to do in a performant manner. It works as a performance
improvement.
Florian: TabAtkins while you're checking on hit testing, can you
document the use cases that need layout and NOT paint
containment?
TabAtkins: Anything that wants negative margins to poke out, they
should be allowed. They don't normally change layout,
but they can happen to have just enough poke out that
you happen to get scrollbars.
Florian: So anyway this is optimization so we don't restrict it we
remove a few cases.
TabAtkins: We restrict it which isn't good. There's a few cases
where if you set it just right you can emulated layout
containment. I'd like to not restrict people when they
have reasonable use.
Rossen: We have a couple of options. 1) put this on ice until you
hear about hit testing. 2) Accept #3 and require hit
testing works. 3) Accept #3 and say hit testing is
optional or not supported.
TabAtkins: What I want is #3 and leave hit testing undefined until
we investigate further. Say we're unsure about hit
testing in the spec and that it will be replaced with
spec text soon.
Rossen: Sound like 3 with optional hit testing.
TabAtkins: No, undefined hit testing.
Rossen: So #3 with undefined hit testing. Objections?
<fantasai> Okay, if called out as an issue
<fantasai> not just left undefined
<fantasai> Rossen^
RESOLVED: Accept #3 from the e-mail (Overflow is allowed visually,
but it doesn't project its "geometry" past the layout-
contained ancestor, so it can't trigger overflow past a
layout-containment boundary) and say hit testing is
currently undefined.
astearns: Rossen you missed fantasai objecting in IRC.
TabAtkins: She didn't object to what I actually said so it's fine.
Rossen: So an issue and it's undefined.
TabAtkins: Yeah.
RESOLVED: Mark the undefined hit testing as an issue.
Styling the disclosure triangle of the <details> element
--------------------------------------------------------
<Rossen> https://lists.w3.org/Archives/Public/www-style/2016Feb/0282.html
TabAtkins: I don't know who put this specifically, but the e-mail
was from Mozilla.
TabAtkins: The <summary> element of <details> is supposed to have
a disclosure element that says if it's open or closed,
but doesn't have good details on how to implement.
TabAtkins: fantasai and I agree it seems reasonable to call
<summary> element a display list item and the
disclosure is a list item. That's handled by disclosure
open and closed. HTML thought it was odd at first, but
were assuaged when I explained. There's a PR pending
that accepts tweeking the UA style sheet to require
that it makes it required.
<zcorpan> i think this is https://github.com/whatwg/html/pull/748
(which is merged)
TabAtkins: HTML accepted this styling and we're okay unless
someone objects.
glazou: Display doesn't cover semantics, but saying details is a
summary list item is pretty terrible.
TabAtkins: When you say it is not a whatever you're implying
semantics.
glazou: Web designers will be confused because they don't have
knowledge of the discussion.
fantasai: This is better than anything on the table.
glazou: Just do an alias, don't use list item.
<zcorpan> ...no
TabAtkins: Another name for list item for this one thing is silly.
glazou: We'll avoid the cost of one string because we're saying
this works?
TabAtkins: Are we adding one string because someone is in theory
confused?
glazou: If you do that in a UA style sheet people can use it
elsewhere. <details> display list item, no one is shocked?
leaverou: I agree with glazou. If people want display of summary
they have to set it back to list item.
glazou: I object formally to this. It's terribly ugly
<zcorpan> i object to adding an alias
TabAtkins: This is HTML's deal.
glazou: So I'm proposing the CSS WG makes a comment saying this is
ugly.
TabAtkins: fantasai and I agree with it. So the CSS WG is torn on
the issue, so I don't know if we can make an official
WG pronouncement.
fantasai: Someone will object in either case.
<zcorpan> glazou: pls file an issue on html
<glazou> I will
<zcorpan> ty
glazou: Let me add one thing. You seem to have been involved a bit
in this, correct?
glazou: Is there anyone in this WG that was involved?
TabAtkins: I suggested it and fantasai supported it and we argued
for it in the HTML group.
glazou: I'm surprised that you're supporting such a thing.
TabAtkins: You've said you disagree.
glazou: I thought we were trying to make things the right way and
we're reusing something not made for that.
fantasai: It is made for that. The list item is a box that is a
block box and generates a marker box. The name is tied
to list, but the meaning is the right behavior.
glazou: There is difference on the marker position that is allowed
on list items and not this. Marker is related to the list
itself.
TabAtkins: No it's not. There has never been a list in CSS; it's
list items that sit in a block box, but we never invoke
a parent.
fantasai: It's just the same as 'display: table/table-cell', which
are named after their use in presenting data tables, but
don't confer that semantic either.
<ChrisL> I agree with fantasai, css display as table can be used
on non tables so this can be used on elements which are
not list items
glazou: Rename list item, then. This is ugly.
TabAtkins: It's an informative update, please feel free to yell at
WHATWG.
ChrisL: I agree with fantasai that you can style any element as a
table if you choose to. So that this is being used where
the element isn't a list item but is being styled like one
is fine.
leaverou: Is there any elements styled as tables by default?
<zcorpan> nope
TabAtkins: Only tables.
leaverou: Exactly.
TabAtkins: If there was any other grid-like elements in HTML they
may get grid-like elements.
Florian: I would expect this in a book by leaverou about neat CSS
tricks, not in the UA style sheet.
fantasai: This does everything that you would expect it to do and
that we want it to do: it generates a block box and a
::marker box and lets you style them and reposition the
marker or suppress it. List item contains all the things
we want. It totally makes sense for using this and not
making a new feature though the name is odd.
Florian: So maybe send a mail to the CSS WG suggesting a new name.
Rossen: So, TabAtkins and fantasai are you looking for a WG
decision?
TabAtkins: No, it's an update. It was HTML's decision. If you
object tell them. You no know what's going on.
<glazou> I will
Rossen: If you want to yell at the HTML group, feel free.
grid-template shorthand
-----------------------
Rossen: Should the grid-template shorthand collapse into the grid
shorthand.
TabAtkins: I'm fine with this.
Rossen: One thing I wanted to check, would that mean that any
ascii syntax accepted for grid-template would be accepted
by the grid shortcut? So any syntax can be grid-template
ascii?
TabAtkins: Correct. Grid shorthand says whatever grid-template
takes.
Rossen: So grid: blah blah; is a valid syntax.
TabAtkins: It has been for a long time. We have grid which has
better resetting we may as well drop grid-template.
Rossen: I see.
<gregwhitworth> for web devs I prefer them using something that
resets stuff based on the flex issues.
fantasai: Grid template syntax is a subset of grid syntax, so
we're making it simpler to authors. Otherwise you'd have
to choose based on reset of invisible things. That's
going to be confusing for authors.
Florian: I've already been confused by this :)
Rossen: Yeah, I guess I wouldn't have objections to this.
Rossen: Any other implementors on the call that would have a
problem?
Rossen: Doesn't sound like it.
Rossen: So you're going to fold the grid-template into the grid
shorthand.
TabAtkins: We'll move the syntax into grid, yes.
Rossen: Simplification is goodness. Objections?
RESOLVED: Remove the grid-template shorthand and fold it into the
grid shorthand.
Events for FontFaceSet
----------------------
Rossen: There was one last topic, but we have one minute.
Rossen: It was just the topic on font faces. There was a question
on what implementors think about it. On our end we're fine.
I think this is for people currently supporting it.
TabAtkins: The only person that has said something is Myles. I
want to hear from FF and our implementor. I'm fine if
other people are fine.
<zcorpan> i think it's not shipped by anyone yet, is it
<zcorpan> ?
Rossen: Anyone capable of talking about this?
TabAtkins: The relevant implementors are HeyCam and Kenji on our
side.
Rossen: Let's push to next week or maybe this is on mailing list
this week.
CSS OM
------
fantasai: Are we publishing on CSS OM some time?
<fantasai> https://www.w3.org/TR/cssom/ 2013
Rossen: We resolved on that in Sapporo.
Rossen: zcorpan?
zcorpan: Sure, we can.
zcorpan: I've made some small changes, but we can publish.
Rossen: It's top of hour and people need to peel off.
fantasai: We were going through a section of CSS OM a month so we
should set that schedule. Ask zcorpan which section to
review.
Rossen: Will do.
Rossen: Thanks everyone.
Received on Thursday, 3 March 2016 00:34:12 UTC