- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 26 Nov 2014 15:33:25 -0500
- To: www-style@w3.org
New WD for CSS Transforms
--------------------------
- Everyone should review Transforms in order to be able to vote on
publishing a new WD next week.
Fixed position creating a new stacking context
----------------------------------------------
- Microsoft is going to test out the changes.
- If it works well, it will be brought back to the group and
likely written into the spec.
Extend :matches() to pseudo-elements
-------------------------------------
- RESOLVED: extend :matches() to pseudo-elements
Specificity of :matches() inside :not()
---------------------------------------
- RESOLVED: The specificity of a :matches() inside a :not() is the
specificity of the most specific
:has-focus
----------
- RESOLVED: reuse the hook from :active on :focus
- RESOLVED: define a new :focus-within that matches on the same
things as :focus, plus parents, including if there are Shadow
DOMs
Applying pseudo classes to the label based on labeled content
-------------------------------------------------------------
- RESOLVED: both :hover and :active should propagate from the
labeled control to the label, in addition to the other
direction.
CSS3-UI issues
--------------
- For text-overflow, the conversation about handling items where,
due to other properties, the text can't overflow ended up
being too complex for the time on the telecon and will go back
to the mailing list.
- RESOLVED: Drop the text that says: "The resize property applies
to elements whose computed overflow value is something other
than visible. If overflow is different in a particular axis
(i.e. overflow-x vs. overflow-y), then this property applies
to the dimension(s) which do not have the value visible."
- For outline offset, everyone agreed that there needed to be
constraints on how far in the negative direction values can
go, but there were several different options as to how the
should be written. Options included:
- Setting 0 as the minimum.
- Set a floor as soon as any two lines of the shape touch each
other.
- Changing the outline of the shape itself and making it
shrink.
- Florian will try and write up a clear and relatively simple
proposal for the mailing list.
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Angelo Cano
Adenilson Cavalcanti
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Daniel Glazman
Koji Ishii
Dael Jackson
Brad Kemper
Peter Linss
Matt Rakow
Florian Rivoal
Andrey Rybka
Simon Sapin
Dirk Schulze
Alan Stearns
Greg Whitworth
Steve Zilles
Regrets:
Simon Fraser
Mike Miller
Simon Pieters
Keshav Puttaswamy
Scribe: dael
glazou: Let's get started.
glazou: I saw a few additions from Florian.
glazou: Let me get them on my screen. Since we have tantek and
Florian we can do them. Are there other extra beyond what
Florian sent?
New WD for CSS Transforms
--------------------------
TabAtkins: I'm all for it.
Florian: Sure.
<dbaron> +1
<tantek> +1
<andreyr> +1
krit: Are the objections since we discussed transform styles at
the last F2F. We still have issues in the spec. It shouldn't
be a huge issue, but people may want to wait. I'd like a new
WD to reflect the changes we have.
MaRakow: I'm still concerned about the implications of some
changes, but I haven't gotten a chance to look at it
fantasai: Do you want to review and publish next week?
MaRakow: I'd prefer that.
glazou: So any comments besides MaRakow's?
Action: everyone review for next week
Fixed position creating a new stacking context
----------------------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Nov/0384.html
gregwhitworth: You can see the link in the agenda. 2 years ago
Rossen and I talked and we were going to make the
change and see if we got egregious issues. We're
going to go ahead and make the switch so our
enterprise customers will say if there's problems.
It would be good to get a resolution.
Florian: You want a resolution first?
Rossen: We'll flight the solution...It would be good to discuss
and see what the area is where we want to be. We don't
want to go back and forth between stacking context and not.
It's hard to gage what blink and webkit intend to do.
TabAtkins: I haven't been able to talk to the implementor, but I
suspect we want to have it. I think maybe Jacob Rossi...
one of our implementors said it makes it easier. I have
to check the thread.
glazou: smfr sent a message just recently saying webkit has no
plan to change in the foreseeable future.
<dbaron> I'd be hesitant to agree firmly to change the spec before
you've done the experiment, but I'm fine with you doing
the experiment and seeing how it goes, with the idea that
we'll change the spec if it goes well.
gregwhitworth: I think us flighting will help the discussion.
Webkit and blink might not get bugs but we may.
We'll flight it and we can come back, I want to get
the discussion going. It would be good to look back
once we get it tested and get a full solution.
gregwhitworth: Does gecko have opinions?
dbaron: I just wrote in IRC. I'm hesitant to agree to change the
spec pre-experiment, but I think you should do the
experiment and we'll change if it works. We'll want to
know if it's a compatible improvement to do it.
gregwhitworth: Sounds good.
glazou: Anything else on this? Is it done?
tantek: gregwhitworth, you're talking about changing the spec so
the first example is a blue sq?
gregwhitworth: Yep. It would create a stacking context essentially.
glazou: Can we move on?
group: Yes.
glazou: I suggest we do item 3 before moving on to CSS3 UI
Extend :matches() to pseudo-elements
-------------------------------------
glazou: This created a long discussion because someone from webkit
already implemented. Before we discuss the mobile, I'd
like to understand why we would do it.
TabAtkins: The use case is like that of :matches, but without the
:matches pseudo it's hard to do. So like without this
spec'ed in style sheets I can use :matches, but I have
to repeat it for the before and after.
fantasai: I think it's effectively a syntactic sugar. You can
write the selectors longhand to be equivalent in such a
way that it should work exactly the same. There's not a
reason not to make it accept a pseudo-element, but we
have to be careful to make sure the syntactic
constraints are there for the shorthand as well as
longhand.
fantasai: TabAtkins, you were having trouble spec'ing it. It
shouldn't be hard, we can do that together.
glazou: Any other opinions? Everyone okay with extending?
TabAtkins: Or having the functionality in some form.
dbaron: I'd want to catch up and see the proposal, but it sounds
reasonable.
glazou: Okay then.
<SimonSapin> +1 with what fantasai said, keep the same constraints
as when written the long form
RESOLVED: extend :matches() to pseudo-elements
glazou: We have two other things on selectors.
<tantek> let's keep going with selectors
Florian: 2 of the things I have are selectors related
Specificity of :matches() inside :not()
---------------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Oct/0530.html
glazou: So Benjamin asked about this on the list and he has a
weird explanation. The two definitions collide and it's
hard to understand what to do.
TabAtkins: The definition of :matches() talks about which selector
matches. If you nest inside a :not() he's arguing that
none of them match so you can't get any specificity.
And wrapping two nots does something really weird with
specificity.
TabAtkins: So he says when this happens, pretend it's the most
specific one.
dbaron: This sounds right to me.
<tantek> this sounds like a good spec clarification
fantasai: Also me. It's making :matches() behave like the longhand
which is how it should be.
<SimonSapin> +1 for most specific
TabAtkins: Using :matches() like the e-mail doesn't add anything.
For continuity, even if you nest inside the large
selector inside a :not() we should act similarly.
RESOLVED: The specificity of a :matches() inside a :not() is the
specificity of the most specific
glazou: Can one of the editors reply on the list?
TabAtkins: Yes.
glazou: There's the last last on the agenda, that's Florian's. We
can go as you wish for the rest of the time.
<dbaron> where's Florian's long list of stuff?
:has-focus
----------
<Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0271.html
Florian: The :hover and :active pseudo classes match on more than
themselves, they also attach to other elements and pierce
shadow DOM. The :focus pseudo doesn't do this and we
probably can't change that for backwards compat reasons.
Florian: It would be useful to do, though, so I suggested a new
:has-focus pseudo class which would propagate through
ancestors.
<fantasai> I think we also don't want to change that, since you
want to know exactly what's in focus
Florian: There's fairly obvious use cases. If you have a form and
want to highlight it you can't do it without JS right now.
Same thing if you want to go through a shadow-DOM. Since
we can't change :focus, I suggest introducing this.
fantasai: I think we don't want to change :focus.
Florian: We can't, but we want something that does the same with
the extension.
fantasai: I think there's reasons why you'd want to go up the
ancestors and reasons why you wouldn't. I think it's a
good idea to add this because it handles a lot of use
cases.
Florian: Also some people suggested we didn't need it because it
was handled by :has, but it doesn't pierce shadow
barriers unless you specifically make it do so.
TabAtkins: Agreed.
fantasai: I think :has-focus, I'm not sure about the label
propagation, I'd prefer that via :focus, but if this is
an ancestor for a focus element it matches.
Florian: Opening the possibility for the host language to match is
appropriate, but if it should do the same is a slightly
different conversation. Opening the possibility is
appropriate and we can leave :focus as is since it's got
a long history of backwards compat.
tantek: I have a concern about confusion from web developers. You
learn about :has and :focus but :has-focus doesn't do what
you think it would from the pieces. Having it named like
that would be confusing.
Florian: I'm happy to bikeshed. It's been called :focus-within and
other options. I'm not attached to the name.
fantasai: I think I agree with tantek. It should function like
:has(:focus) if it has :has-focus as a name.
fantasai: I think that it's okay for it to also pierce shadows, I
don't think it's okay for the host language to customize
:has except through customizing :focus
Florian: I'm a bit confused. Are you saying it should be unfocused
directly?
fantasai: If the host language wants to change, it changes through
:focus and can't change :has-focus except that it is
defined in terms of :focus. It's a general principal I'd
want, but the name makes it more important.
tantek: You want to minimize the number of interface points
between specs. If you use how the host language uses
:focus, that's the hook for the host language.
Florian: So if the host language can modify :focus, that's great.
If not I'd like to introduce it on the new thing, no
matter the name. It currently does on :active, not on
:focus. :focus just matches the focus thing.
Florian: That's why I'm trying to introduce this on the expanded
focus.
tantek: I'd rather allow a hook on :focus that's reused instead of
saying you can hook into :has-focus.
Florian: If we can I'd prefer that too.
fantasai: Is this the label thing? I think there's no backwards
compatibility issue, just implementation issues.
tantek: Can we re-use the hook on :active?
Florian: We can try and say it's the same hook as :active if
there's no backwards compat issues. If we can do that
that's best.
Florian: Should we try and resolve on that? So we resolve that we
use the hook on :active for :focus and we create a new
element that is like :focus but pierces shadows
tantek: If you're looking for a name to use, :focus-within works.
Florian: Especially if we're using the hook on :focus.
tantek: And we can bikeshed on that name later.
<Florian> RESOLVED: reuse the hook from :active on :focus
<Florian> RESOLVED: define a new :focus-within that matches on the
same things as :focus, plus parents, including if there
are Shadow DOMs
Florian: Alright.
<tantek> Sounds reasonable
glazou: No objections on those two resolutions?
glazou: Adopted! Let's move on.
Applying pseudo classes to the label based on labeled content
-------------------------------------------------------------
Florian: The other topic is related to this. Currently the hook on
:active and the definition of :hover both propagate from
the label to the labeled control, but not backward. If
the control is active the pseudo won't match on the label.
I think it's better to go both ways.
Florian: I raised that on whatwg and there were few answers. The
answers was that the current direction is 1-1, but the
other direction was 1-to-many.
gregwhitworth: We ran internal tests and we've never had issues
regarding this. Their math works, but in the real
world you won't hit this problem. I ran something
with 5,000 <div>s inside a label and it was only
milliseconds of difference, so I don't think it's a
problem.
Florian: In general, it makes sense to go in both directions. Now
that the hooks are separate we might want to decide
separately.
glazou: Other thoughts?
<tantek> Curious what dbaron thinks about this.
<dbaron> I don't particularly care.
<tantek> Then I'm willing to go with consensus as well.
<tantek> No strong bias.
fantasai: I think having it go in both directions make sense.
TabAtkins: I agree as well.
Florian: So we should go back to the whatwg and say the CSS group
agrees it should work both ways.
<Florian> RESOLVED: both :hover and :active should propagate from
the labeled control to the label, in addition to the
other direction.
glazou: no objections?
[silence]
Action: Florian to ping the whatwg on the above resolution
<trackbot> Created ACTION-662
Florian: So to CSS3-UI or finish the agenda?
glazou: We finished the regular agenda.
CSS3-UI issues
--------------
Florian: We'll do these one at a time and see how far we get.
<Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0425.html
Florian: This is the first comment, it was half of a change was
done. Did you forget the other half or decide not to do
it?
tantek: Likely accidental. I was trying to be conservative with
the edits, but that was probably unintended.
tantek: So this was line box. I'm reading.
Florian: So, basically, do we overflow onto the float?
tantek: The suggestion is reasonable. I can make the change. I
guess I just didn't make the edit.
Florian: I have no opinion- just trying to guess why you didn't do
it. Browsers are interoperable along the current spec.
The question would be to implementors, would you make the
change if we spec it?
Florian: It seems reasonable, but we're interoperable in another
way currently.
Florian: If you have text-overflow ellipsis and we're overflowing
onto the float, does the text overlap or do we apply the
ellipsis?
Florian: Currently the spec says you overwrite. Everyone does it
according to text.
tantek: I think Gecko would change to have the better behavior.
There's aspects that are interoperable, but things like
handling scrolling aren't. So do we look at this as a
forward looking change, or is it a compat issue?
Florian: If browsers will change I'm happy.
Rossen: With this edge case, and it's very edge, from a usability
point of view, let's say you apply the ellipsis, but if
your text is colliding, how would you scroll that? I'm
assuming in that test case you can't scroll, so why would
you hide?
tantek: So that you don't overlap and have it look ugly.
Rossen: How can you get to that case? Do you have a test case that
shows it? I just can't picture how the text would overlap
with the float. Unless this is a bug, the float for the
text should be one over the other.
Florian: I have a test case, hang on.
<TabAtkins> https://bug944200.bugzilla.mozilla.org/attachment.cgi?id=8340052
<Florian> https://bug944200.bugzilla.mozilla.org/attachment.cgi?id=8339998
tantek: I think the test case from TabAtkins is the right one.
Florian: Yes. We're talking about the third line.
Rossen: The one that you just pasted?
Florian: The third line in TabAtkins's linked example.
tantek: In this case the third line, what happening is the text is
overriding...normally text would wrap around the float.
It's only overlapping because the white-space no wrap.
Rossen: Yes, I see. I missed that part.
Florian: So what we're currently seeing is correct by the spec.
We're proposing a change
tantek: Rather than drop the visible requirement, there's
something else causing the overflow. That's why we should
consider the case. Or the line box has a whitespace that
doesn't allow wrapping, we're basically talking about
conditions where the text can't overflow.
Florian: I think that's already addressed by the spec. I think so.
tantek: I didn't think it was but okay.
tantek: This seems deeper than we thought it would be. It sounds
like the spec change to make this requires more iterations.
Florian: Take it back to the list?
tantek: Does that seem reasonable? The whitespace no wrap
relationship should be well understood.
Florian: That is, but the float bit needs to be looked at. Back to
the list. Next one?
tantek: Sorry, I thought that would be easy.
<Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0445.html
Florian: Still on overflowing. This is issue 37. We have it
spec'ed that the resize applies to non-visible overflow
and if that's the case in only one direction it applies
in only one direction. But you can't have that in only
one direction because everyone is interoperable that if
you have overflow in one direction visibility is set to
auto.
Rossen: Anything other than that behavior would be a nightmare to
implement.
Florian: I'm suggesting we remove that bit of text since it's
trying to hook into something that doesn't happen. If we
have visible in only one direction we have it become
auto, so visible set in only one direction doesn't happen.
fantasai: It's a case that doesn't happen.
tantek: So we need to say something else.
Florian: So I proposed a note that says it's not possible, but if
later that becomes possible we'll need to define the
behavior.
tantek: So we apply both directions?
Florian: Yes. Currently the spec pretends there's another
possibility.
tantek: I agree with TabAtkins that we drop it with no note.
fantasai: We have a case that's slightly different where there's
regions where you paginate in one direction and scroll
in the other. That's a case to think about.
Florian: For regions the fragment isn't on the overflow property.
Even if you're fragmenting you only have one direction.
There's no need for something special. For the overflow
fragments, the spec isn't stable and we don't know what
will happen.
Rossen: I agree. Regions, the only extra constraint is how much
content you have, not what happens with content layout. I
don't think we can get in situations where one direction
overflow is visible and the other one it's not.
Rossen: So dropping this?
Florian: That's my recommendation and add a note if someone is
concerned
Rossen: I'm up for it.
glazou: Everyone agrees?
RESOLVED: Drop the text that says: "The resize property applies to
elements whose computed overflow value is something
other than visible. If overflow is different in a
particular axis (i.e. overflow-x vs. overflow-y), then
this property applies to the dimension(s) which do not
have the value visible."
<SimonSapin> Florian,
http://www.w3.org/Style/CSS/Tracker/actions/662 lacks some context
<Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0449.html
Florian: The spec doesn't put any constraints on the outline
offset, so you can put it -9000 which isn't interoperable.
There's been discussion, but no conclusion. There's no
reason to forbid small negatives, it's only a problem
when the outline smashes into itself.
Florian: The option C in the e-mail isn't great. Another is when
it slams into itself, but you preserve 1 pixel, or
preserve the entire thickness which is my favorite.
tantek: What do implementors do?
Florian: They disagree. In Chrome it disappears, in Firefox if you
have 1 pixel outline and a large negative offset it has a
large black area. So a 10 pixel high box and a -9000
offset, you get a 1000 pixel black thing. It's not
interoperable
Rossen: The outline offset to me...the reasonable behavior to
expect is if you consider the content box and border box
you use padding to offset them and that lets you move the
border box from the content. We don't allow negative
padding, I don't see a reason that outline offset
shouldn't be considered the same way. Once you distance
outline box from padding box, I don't think why you'd want
to constrain inside.
Florian: So allow no negative values?
Rossen: Yes.
Rossen: If you draw parallels between how padding is used, it's an
offset for border box, so outline-offset is the same thing.
We don't allow negative padding.
tantek: It's because the use cases for drawing an outline are
different than a border. I appreciate simplifying the
model, this was deliberately allowed.
fantasai: I think we should say the area constrained by the
outline is floored at 0 so you can't have overlap no
matter the shape. If it's an hourglass it might turn
into a 0 width square.
Florian: But if you start non-rectangular and shrink, I would
block as soon as two sides hit each other.
<BradK> +1 on stopping the offsets once two edges touch each other
* fantasai happy for UA to have higher limits
* fantasai e.g. letter-spacing has UA-defined limit on negative
values
dbaron: I'm a little worried that you're getting into defining a
complex algorithm for an obscure case.
Florian: I'm trying to define and make it not disappear because
it's useful for :focus.
Rossen: tantek, can you explain the major use case you're trying
to achieve?
tantek: There's UIs that have a glow where you want to overlap. I
believe that's why it was introduced. I share the concern
about trying to over specify an algorithm. We might be
able to say use the metrics of the border box and you
can't go negative beyond what would 0 out the border box?
tantek: You can go negative into the border box, but you can't
completely eliminate it.
Rossen: So you want the inner border box edge?
tantek: It has dimensions and overall width. You divide that by 2
and that's a clamp.
fantasai: Maybe define as not changing the outline set, but
changing the outline of the shape being drawn. Right now
you have various border boxes and we can say this
shrinks the box you're wrapping around. If you have a
non-rectangular shape, the boxes you're wrapping around
shrink.
Rossen: What do you exactly define as shrink?
tantek: I was trying to specify in terms of the border box.
<tantek> computed value
Florian: To make it more complex, presto does it differently where
if you have a way to flow outside the box you can also
get it non-rectangular. Something sticks out and you draw
outside that non-rectangular.
tantek: We have no obvious solution. We need someone to make a
simple proposal on the mailing list that isn't too
algorithmic but also handles it reasonably.
Florian: I can try and do that. So are we looking for perfect
interoperability or just keep boxes from disappearing?
Rossen: We want interoperability and please consider inline and
outline where they overlap.
Florian: And we don't have interoperability on outline.
fantasai: I want interoperability. We should have to spec so we
limit bad things.
Rossen: And we want interoperability because without that there's
no reason.
Florian: Short of defining it, we need to make it so that it works
for people trying to do common things.
fantasai: Letter-spacing says you can do it but there's UI limits,
those just aren't defined.
tantek: We need simple limits that don't make it useless.
Rossen: And real examples so that we can see what reasonable means.
Florian: I'll give it a shot and get back to the list. Rossen,
I'll send you an e-mail to help me understand IE behavior.
Florian: I have more, but that's next week.
glazou: Thank you.
Received on Wednesday, 26 November 2014 20:33:53 UTC