- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 30 Apr 2015 09:07:44 -0400
- To: www-style@w3.org
Paris Houdini F2F
-----------------
- Rossen confirmed that the Houdini task force would be meeting 28
and 29 August after the CSS F2F hosted by Mozilla.
- If anyone is planning on attending, please add their information
to the wiki: https://wiki.css-houdini.org/planning/paris-2015
Rounded Displays and Flexbox
----------------------------
- Most of the group was supportive of an exploration of the
relationship between flexbox and rounded displays.
- It was agreed that this didn't belong in level 1 of flexbox, but
should instead exist as an exploratory section of the rounded
displays spec and/or a wiki and mailing list thread with the
conclusions potentially being integrated into flexbox 2.
@media not
----------
- RESOLVED: In media queries, use 3-valued logic with maybe semantics
to handle unsupported syntax, i.e. false and unknown =
false. (Re-evaluate if this ends up with back-compat
problems.)
AnimationEnd events and display: none
-------------------------------------
- RESOLVED: No animation events when subtrees are destroyed.
- RESOLVED: Start a next level of transitions with dbaron as an
editor.
/deep/ combinator
-----------------
- RESOLVED: Drop /deep/ from dynamic profile and record an issue
about keeping it in the static profile.
Splitting up the Containment Value
----------------------------------
- RESOLVED: Do layout containment, split containment into three
pieces as per TabAtkins' proposal
(https://lists.w3.org/Archives/Public/www-style/2015Apr/0364.html)
and have overflow: clip
CSS 3 UI
--------
- It was agreed that the coordinate systems need to be better
defined, but that the definition belongs in CSS Image.
- The CSS Image authors will do more research and create edits to
the spec and CSS 3 UI will reference CSS Image.
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Bo Campbell
Adenilson Cavalcanti
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Dael Jackson
Peter Linss
Michael Miller
Edward O'Connor
Anton Prowse
Florian Rivoal
Andrey Rybka
Simon Sapin
Hyojin Song
Alan Stearns
Steve Zilles
Regrets:
Sanja Bonic
Brad Kemper
Greg Whitworth
scribe: dael
plinss: Let's get started
plinss: Anything to add?
Rossen: I have one.
Rossen: Just an update about the Houdini meeting in August.
plinss: Anybody else?
bcampbell: I am going to NY as long as we can talk about some of
the things we spoke about earlier with flexbox. I'd
like to know who to speak to about the agenda for the
NYC and if we can set aside some time for the a11y and
flexbox.
plinss: Generally for a F2F there's the wiki and you can feel free
to edit that and add topics and we schedule exact times at
the first day of the meeting.
Paris Houdini F2F
-----------------
Rossen: Mozilla has agreed to host us and the meeting will take
place Fri and Sat following CSS with ends on Thursday. I
don't have a calendar but I believe that's Aug 27 and 28.
So please, there is a wiki set up so if you haven't please
sign up. That's about it.
<dbaron> It's August 28-29.
<dbaron> https://wiki.css-houdini.org/planning/paris-2015
Rossen: Any questions?
plinss: First two items on the agenda were resolved.
Rounded Displays and Flexbox
----------------------------
<dbaron> https://lists.w3.org/Archives/Member/w3c-css-wg/2015AprJun/0064.html
TabAtkins: I'm mildly opposed to doing new rounded display stuff.
I want to wait for everything else to catch up and
exist. Especially for expansions to flexbox which would
be complicated.
Rossen: Why would you assume these would be in the current flexbox
draft?
TabAtkins: They don't have to obviously but then we're working
further into the future than we'd like.
Rossen: That's kinda preventing or slowing the work of rounded in
favor of existing flex or grid, I don't feel I'm okay with
that. I think it's worthwhile to keep in mind rounded
displays as we make progress and close on flex and grid
with the mind where we're not preventing anything for
rounded completely.
Rossen: However, I don't want to delay these specs for rounded.
glazou: This is a surprise to me. We didn't let hyojin go first so
he can explain why this is a good match. I'd like to hear
hyojin.
* glazou notes that another major vendor announced rounded
displays this week : samsung...
* Florian saw that too. Happy that LG is leading the
standardisation
hyojin: I'm pleased to meet you. I see the flexbox spec, I think
it is related to round display. I'm wondering is it right
to progress on finding round display now.
hyojin: I don't know about the progress of flexbox.
fantasai: I think exploring how flexbox and rounded work together
in better ways is worth exploring. We can't do that in
current flexbox, but the rounded display module can have
an exploratory section for flexbox and in that case when
things become more settled we can put it into flexbox
level 2. It's good to explore these things and to see if
these settings you're prop solve the problems.
fantasai: If we get to a point where we're ready to add to flexbox
we can start a level 2
hyojin: If it's reasonable to progress, I can describe properties
or technology. I can prepare those things. I don't want to
delay flexbox spec progress.
Florian: I don't know if we can directly reuse the flexbox
properties, but at least reusing the concepts certainly
sounds useful. Polar coordinates as proposed in css-round-
display suffer from the same kind of problems as abspos
in terms of collision. Having flexbox-like abilities to
decide which elements should stay fixed size, and which
should grow or shrink depending on available space sounds
useful. I don't know exactly how that would work, but it
certainly is worth exploring.
<tantek> was going to say the same thing about polar coordinates
and flexing. Thanks Florian :)
<TabAtkins> In general, I'm mildly opposed to new display modes in
general ("round flexbox" is effectively something new
compared to "flexbox"), as I think we should just
focus on custom layout, and *then* only develop new
layout modes that are proven to be popular in practice.
tantek: [expresses a desire to see use cases or diagrams about the
desired effects of the combination of rounded display and
flexbox]
<fantasai> tantek++
<tantek> would be nice to see a separate draft that documents
diagrams and use-cases of the desired design effects
<tantek> and that can better inform our discussions
Scribe: TabAtkins
hyojin: I agree that Flexbox level 2 is a good place to start
thinking about rounded display.
Florian: I agree with tantek that seeing diagrams or use-cases
would be good. I'm not sure it should be a draft yet; a
mailing list or wiki would be more appropriate. But
regardless, having some examples would be very
interesting.
plinss: Agreed.
hyojin: Okay.
<tantek> (and yes - format draft/wiki/email is up to author)
@media not
----------
Florian: On the call it seemed like a good idea to have 3-valued
logic to deal with unknown media features or general-
enclosed.
Florian: On the ML, though, we realized there are two different
types of 3-valued logics we can use - a "maybe" or a
"bottom".
Florian: "maybe" makes more sense, but has a greater chance of
breaking backwards compat.
Florian: Tab also proposed a 4-valued logic with both values, but
it's probably too complex.
TabAtkins: I agree that it's too complex.
* fantasai is confused, but will be satisfied if dbaron thinks the
proposal is sane
Florian: I'd prefer to go with "maybe"; it's nicer, and I think
the compat risk, while it exists, is moderate.
Florian: But if browsers disagree, then we should use "bottom".
Florian: The difference between "maybe" and "bottom" is that if
you have "(false-thing) and (maybe-thing)", it's false.
If you have "(false-thing) and (bottom-thing)", it's
bottom.
Florian: False and unknown being unknown is safer for backwards
compat. but false and unknown being false is a nicer
system to work with.
TabAtkins: Yes, because it preserves De Morgan's laws.
Scribe: dael
fantasai: False and unknown = unknown is bottom. Other is maybe.
Maybe makes sense to me.
Florian: But maybe semantics are less backwards compat.
TabAtkins: The ones that were problems, in MQ 3 semantics it
became not all. In the new semantics the prefix would
be a 'maybe' or 'bottom', then a not screen and when
screen is false when printing you have the same problem
with a big 'not' negating everything.
<fantasai> The example was "not screen and (-webkit-foo)"
<fantasai> Which would evaluate to true when printing
<fantasai> But is currently thrown out by non-webkit browsers
TabAtkins: When false and bottom equals bottom it stays false when
exiting which matches MQ3 semantics. It looks to be
very very rare. In order to get it you have to have a
MQ starting with 'not' and a prefix thing ending with
it. It happened twice in the database we looked at.
TabAtkins: Unless somebody feels bad with this I'd like to go with
'maybe' and allow, if necessary, to change to bottom
later. I think the compat risk is small enough we don't
have to worry.
fantasai: That makes sense to me, I'd like dbaron's take on it.
TabAtkins: Okay.
<dbaron> I don't really have an opinion (right now, anyway)
plinss: Objections?
RESOLVED: In media queries, use boolean maybe semantics to handle
unsupported syntax, i.e. false and unknown = false. (Re-
evaluate if this ends up with back-compat problems.)
AnimationEnd events and display: none
-------------------------------------
TabAtkins: If you have a running animation and a display: none it
stops, but does it throw an end? Currently browsers
don't. Later if we add animation cancel events that
will change the subtree. Right now no events get fired
when an animation stops due to a display: none
smfr: I agree with that.
<andrey-bloomberg> no issues
dbaron: I agree as well, though I have a follow up.
RESOLVED: No animation events when subtrees are destroyed.
dbaron: Are people okay with starting the next level of
transitions and animations where we add in cancel events?
<dbaron> transitionstart, transitioncancel, animationcancel
<dbaron> (and as a delta spec)
plinss: Any objections?
<astearns> +1 to new diff draft
Rossen: Go ahead
<glazou> +1 to what dbaron said
RESOLVED: Start a next level of transitions with dbaron as an
editor
/deep/ combinator
-----------------
TabAtkins: In the recent shadowDOM meeting there was discussion on
simplifying. One of the conclusions was the ability for
CSS to easily reach into shadows like this is probably
bad. They resolved to remove that combinator. The other
option is removing from dynamic profile. A few people
preferred that. So either removing it or just having it
in the static profile.
TabAtkins: I'm not sure if we need to resolve, it might be better
to let webapps decide, but we need to be aware.
plinss: That's why I added it to the agenda, to have discussion.
TabAtkins: Related there are simplifications to shadowDOM to make
it a bit easier.
plinss: Other thoughts or opinions on shadow combinators?
<glazou> +1
hober: It was a strong consensus to drop /deep/ I'd rather that
than keep in static.
plinss: I tend to agree. There was discussion in TAG and the
opinion is people want a better module to describe the
style instead of reaching into the DOM. It might be
dangerous to keep this.
TabAtkins: The reason people argued for it is there's nothing
preventing you from walking the DOM manually. The point
it to make that unnecessary. It doesn't expose worse
information, it just makes it possible to do from the
query selector. We can discuss that with webapps.
fantasai: So no resolution on that?
TabAtkins: I'm not seeking a resolution.
plinss: Did you want one fantasai?
fantasai: If we have consensus I think we should resolve
Florian: I think we have it on dropping from the dynamic profile.
fantasai: So maybe mark it as an issue.
RESOLVED: Drop /deep/ from dynamic profile and record an issue
about keeping it in the static profile
Splitting up the Containment Value
----------------------------------
<Florian> http://dev.w3.org/csswg/css-containment/
<plinss> https://lists.w3.org/Archives/Public/www-style/2015Apr/0364.html
TabAtkins: At the extensible web summit we had a nice session
about the containment value. It came out that the issue
in the spec where we should maybe split is something we
should address. What I proposed is to split it into the
3 things it does.
TabAtkins: Layout containment, the element doesn't pay attention
to children in terms of layout so nothing can cause
extra layout. Paint containment so you have a clipping
boundary. Style containment which is a couple of styles
that can influence the rest of the document can no
longer do that. The effects of things in the style
element can't effect the rest of the doc like counter
increments.
TabAtkins: These are the three general areas that the proposal
addressed. I split this to three keywords, layout,
paint, and style and keep the strict keyword to turn on
all three of them. If you need to be flexible in some
ways you can just turn on what you're okay with.
Florian: First you say split everything in the sec, but the spec
currently doesn't have layout containment right now and I
really want that.
TabAtkins: That was an oversight on my part. It'll be there.
Florian: For paint containment, it does three things. Do the same
as overflow: hidden, don't allow scrolling, establish a
containing block for abspos and fixedpos
TabAtkins: It doesn't do anything with scrolling.
Florian: If you define the way you have you can get clip overflow
without the ability to scroll with containment: paint and
overflow: visible, and clip overflow with the ability to
scroll using containment:paint and overflow: auto. What
you don't get the ability to do is containment: paint
and overflow: visible, but still be able to use properties
like overflow-text and resize, which depend on overflow
not being visible. I would suggest add to overflow:
something, perhaps clipped, that does the same as hidden
but with no scrolling.
Florian: So that first if you use containment: paint and overflow
is visible it will do clip but will allow you to resize
and other related properties. It also allows you to do
this without establishing a new containing block for
abspos and fixedpos, which you couldn't do if you only
had containment: paint.
TabAtkins: This all makes sense. I am okay with this. So add an
overflow: clipped and have overflow: visible if it's
doing paint compute to overflow: clip as well.
* fantasai suspects Mozilla has a clip value already
smfr: Is containment supposed to effect other properties?
TabAtkins: It has some effects, but not the computed values.
smfr: In other cases we say it doesn't effect computed values. I'm
worried about properties that override other properties and
creating circularity.
TabAtkins: This is why we track computed values on the wiki to see
if we introduce a circularity. So far we haven't.
<andrey-bloomberg> just my 2 cents - this is quite useful from
developer perspective
SimonSapin: When we split things between style and layout in
paint, is it something that's related to the feature,
or just the current impl do things in a way?
TabAtkins: Layout and paint are completely different things.
That's not impl specific. They are usefully independent.
We can come up with use cases that want one or the
other. Style containment, I don't think it has an
independent life, but having it separate works better
for the overall design.
Florian: I have a hard time thinking of containment style without
layout, but I'm okay with it separate.
SimonSapin: It's not the same as containment, but we think of
layout transition being different than paint. That's
impl specific though because when you animate the top
property it requires layout, but some times you can do
it in the thread.
TabAtkins: The general definition of layout vs paint is somewhat
impl specific, but in the case of contain they're
different.
Florian: And in the containment case, the definition isn't
ambiguous.
??: Correct.
Florian: To answer a comment from fantasai earlier, she says that
she thinks Mozilla has this, and she's correct. They have
this.
<Florian> -moz-hidden-unscrollable
dbaron: When I saw the split property I thought style was
referring to selectors so I'm not sure the name gives a
good sense of what it's containing. I wouldn't want
something to refer to selectors.
TabAtkins: Agreed.
dbaron: I don't have a better idea on name.
TabAtkins: I can put in style isn't an ideal name and we can
bikeshed on the mailing list.
plinss: Do we want a resolution on overflow: clip?
Florian: I think we can resolve to do layout containment, split
into three values, and have overflow: clip
plinss: So objections to those proposed resolutions?
Rossen: Can you repeat?
Florian: One is to make sure the containment spec does layout
containment. Next is split the values of containment as
described by TabAtkins. Last is to have effects of
containment: paint go through overflow: clip
Rossen: Question: in overflow: clip in the case where clipping
element isn't the containing block, will the effects also
clip?
Florian: Overflow: clip visually does the same as overflow hidden,
but you don't get access to scrolling.
Rossen: In hidden your fixed element is still a fixed element and
effects layout of the root element because there may be
scrollbars.
Florian: Overflow: clip alone doesn't change that, but if you do
containment: paint it switches.
TabAtkins: One of the main reasons is to invoke the machinery that
relies on overflow being non-visible.
Florian: When you do containment paint you want overflow: clip and
the containing block.
Rossen: And a stacking context. So this is kind of the god
property.
Florian: So overflow: clip does the same as hidden minus the
scrolling and the rest of what you need for paint goes
through the containment: paint property.
Rossen: Sounds reasonable.
<dbaron> That sounds pretty different from overflow:
-moz-hidden-unscrollable, which is otherwise like visible
except it clips overflow
<fantasai> it should be equivalent to overflow: visible, except
you don't draw outside the box
<Florian> dbaron: overflow:clipped is the same as overflow:
-moz-hidden-unscrollable as far as I can tell. But
containment:paint invokes this PLUS the rest (containing
blocks, stacking context)
<dbaron> Florian, I think they're different w.r.t. establishing a
new BFC.
<Florian> dbaron, That's not documented on MDN.
smfr: It needs some wording for if you try and scroll and if you
transition to clip do you snap to the top.
TabAtkins: I don't know if anything in visible says you can't
scroll, but that's what it does. If it doesn't we'll
make up language and you can reset to your scroll
position. It'll be immediate.
fantasai: It'll be exactly like visible but you don't draw outside
the box.
plinss: objections?
<andrey-bloomberg> all for it
plinss: To any of the resolutions.
RESOLVED: Do layout containment, split containment into three
pieces as per TabAtkins' proposal
(https://lists.w3.org/Archives/Public/www-style/2015Apr/0364.html)
and have overflow: clip
CSS 3 UI
--------
Florian: There aren't many issues left. Let's start with this.
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Apr/0193.html
Florian: When you specify an image for a cursor you can specify
the coordinates of the hotspot. What they mean is obvious
when you point to a bitmap via url(), but since <image>
also lets you do gradients or image-set(), it's less
obvious how coordinates work then. If you have different
resolutions you can only set one set of coordinates.
We need to define how it would work in all kinds of
<image>s.
Florian: For gradients they don't have a natural size in pixels,
the unit could be set so that 50 gets you in the middle.
The way I propose we solve it is we define the coordinate
space of every possible <image> type in css-images and
refer to that in css-ui.
smfr: If you set a repeating linear gradient as your cursor image
what happens?
Florian: The size is defined as impl dependant, through the
"default" and "concrete object size".
Florian: This is defined so the UA decides how big the painting
area should be. The UA defines and then you have a size
and coordinates, but you don't know what those
coordinates are. I suggest that 50 is right in the
middle.
Florian: Currently the spec says these coordinates are in the
coordinate space but we don't define what the coordinate
space is, but I think we should do that.
tantek: For these more challenging image types, do we have
support?
Florian: I think we have at least interest in implementing or
actual support for image-set.
tantek: My understanding is we don't for things like gradients. I
don't think there's browsers that support that.
Florian: I think for image-set someone does or has intent.
tantek: I don't think...image-set is new for browsers in general.
I'd be surprised if they support them for cursors.
Florian: I think someone said they want to but haven't done it.
tantek: We might want to capture informative guidance, but I think
normative language, I would oppose that.
Florian: Now we have wording that doesn't mean anything we say
it's in the coordinate space. I just suggest we defer to
image values.
tantek: That I agree with. I resisted specifying it in css3 ui.
Florian: We might want a note in css3 ui, but not define. We might
want a note on image-set.
tantek: That's reasonable. If we have a reasonable note that
reflects what's going to happen. Who edits image?
* fantasai and Tab
Florian: TabAtkins and fantasai
fantasai: I think spec coordinates makes sense.
<TabAtkins> I'd actually prefer we allow %s, and define that
integers, when used on an image without coordinates,
all refer to the start/start corner.
tantek: Will you take an action?
fantasai: We can to edit the spec, but we have the same problems
in other places. We can take an action to see what Media
Fragments is up to.
fantasai: We need to define for CSS formats anyway.
Action: fantasai to edit CSS Image and specify how to determine
the coordinate system of the image
<trackbot> Created ACTION-683
Florian: There are some values where it's not obvious for what it
should be, but we can get vocabulary quickly even if the
behaviors are in the air. We can anchor to the right
terms.
tantek: And now we can put a note in CSS 3 UI to check that draft
for details.
plinss: It sounds like a plan.
Florian: So a note for now in CSS 3 UI and text is added to image.
fantasai: For x and y can it take percentages?
Florian: Only numbers.
fantasai: It might make sense to spec as percentages. Especially
if you have multi resolution, especially if you have
pixel values.
plinss: We don't have time to discuss it, but I have a follow-up
on why we don't allow any lengths.
<tantek> short answer is: current support
plinss: We're at the end of the week. Thanks everyone, talk to you
next week.
<fantasai> tantek: I'm not so sure we need <length>, but I think
<percentage> would've been more useful than <integer>.
Maybe for the next level
<fantasai> tantek, florian: Also, <x> and <y> should be <integer>
{1,2|
<tantek> fantasai - yes to next level
<fantasai> (in the spec)
<Florian> fantasai: why {1,2}?
<Florian> tantek: for the other css-ui issue
<Florian> tantek:
https://lists.w3.org/Archives/Public/www-style/2015Apr/0328.html
<Florian> tantek: do you mind if I just go ahead and add the may
to the spec?
<tantek> Florian - checking for context of "may"
<Florian> Implementations may substitute a more language, script,
or writing-mode appropriate ellipsis character, or three
dots "..." if the ellipsis character is unavailable.
<Florian> tantek: I'm just adding writing modes to the list
<tantek> yes that looks good go for it
Received on Thursday, 30 April 2015 13:08:12 UTC