- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 30 Jul 2015 07:47:23 -0400
- To: www-style@w3.org
Publishing Grid Layout
----------------------
- RESOLVED: Publish updated WD of Grid layout
CSS Break
---------
- There was still no consensus on what to do with the name 'any',
though it was agreed to be troublesome. Possible solutions
were:
- Accept the name
- Rename it
- Push it to level 4
- Change 'always' to 'all' so that 'any' would make more sense
- There was no consensus so discussion will continue on the
mailing list
Percent resolution for abspos vs inflow grid items
--------------------------------------------------
- As this issue is dependent on a F2F topic, a final decision will
hold off until the Paris meeting.
Interaction between overflow-x and -y
-------------------------------------
- There were three proposed solutions to address overflow: clip
- A) "overflow: clip" is a paint only operation, it does not
(on its own) create a BFC, and if "contain" is not
"paint", you can have "overflow-x:clip" in one dimension
and "overflow-y:visible" (and vice versa). Amend the
definition of "resize" and "text-overflow" (and anything
else that depends on "overflow") to deal with the new
possibility of being visible in one dimension only.
- B) Rename to "overflow: hidden no-scroll". It creates a BFC.
If you specify it in one dimension only and leave the
other visible, the visible one computes to auto.
- C) Don't introduce a new value to overflow, make
"contain:paint" cause "overflow:visible" to compute to
"overflow:hidden", and implement heuristics to detect when
browsers should avoid allocating the resources needed to
do the scrolling.
- The group first discussed the merits of A before deciding to
rule it out completely.
- C seemed like the ideal case, but browsers weren't capable of it
yet, so the group decided on B.
- RESOLVED: pick option B behavior, defer naming to editors,
everyone complains if they pick something bad
- There was a mini bikeshedding session after the telecon on IRC
where 'clip' and 'none' seemed to be the most favored, but the
decision is still up in the air.
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
David Baron
Bert Bos
Tantek Çelik
Alex Critchfield
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Dael Jackson
Brian Kardell
Brad Kemper
Chris Lilley
Peter Linss
Myles Maxfield
Michael Miller
Anton Prowse
Matt Rakow
Florian Rivoal
Simon Sapin
Alan Stearns
Lea Verou
Greg Whitworth
Steve Zilles
Regrets:
Sanja Bonic
Adenilson Cavalcanti
Dave Cramer
scribe: dael
plinss: Let's start. Please add your name to IRC so we know you're
here if you haven't.
plinss: Anything to add to the agenda?
fantasai: Publish grid layout?
plinss: Anything else?
Florian: Just to mention I asked for a week to review the proposed
prefixing policy, and I did send it, but it was only sent
two minutes ago so there hasn't been time to reply
<gregwhitworth> We read it, I forgot to send feedback
<gregwhitworth> florian: my bad
<Florian> gregwithworth: no problem: I'm the one sending 2 minutes
before the deadline. Comments on this new mail
appreciated:
https://lists.w3.org/Archives/Public/www-style/2015Jul/0446.html
Publishing Grid Layout
----------------------
fantasai: TabAtkins and I made a bunch of edits to fold in
resolutions for grid layout.
<fantasai> https://drafts.csswg.org/css-grid-1/ changes
<fantasai> https://drafts.csswg.org/css-grid-1/issues-wd-20150108
<Rossen> +1 on publishing
fantasai: We tracked the comments for this cycle. There's a couple
of open issues, but we want to publish a WD to update
what's out there and we wanted confirmation from Rossen
specifically but the rest of the group too.
Rossen: I went over your changes and I'm fully supportive of
publishing a new WD.
fantasai: If anyone wants more time to look that's fine, but if
you want to publish next week that's fine too. We want
it out in the next few weeks and to keep working.
plinss: Any objections?
RESOLVED: Publish updated WD of Grid layout
fantasai: I'll aim to publish next Thursday.
CSS Break
---------
plinss: Looks like we wanted to get back to that this week.
fantasai: Two issues...one was dropping cloned margins at the
breaks and the other was naming of any. I can't remember
if we closed on the first issue.
Rossen: I thought we resolved on dropping margins and the name was
up to debate, but I didn't hear anything better than 'any'.
fantasai: If we had 'all' and 'any' it would be clear, but since
we have 'always' which doesn't make sense for multiple
types of breaks...has anyone impl the unprefixed break
other than Opera?
Rossen: We have not.
fantasai: I think Mozilla has not. Blink? Safari?
<dbaron> I think Gecko still has only page-break-{before,after}
smfr: I don't think webkit has.
fantasai: Okay. So I think we've got several possibilities:
<fantasai> 1. Change nothing
<fantasai> 2. Come up with a different name for any
<fantasai> 3. Change 'always' to 'all' and leave 'any' alone.
Rossen: The last e-mail I replied I did summarize what we talked
about for renaming 'any' and no one replied.
fantasai: I think there's three things that makes sense [reads
list above]
fantasai: I think one person said 'any' for fragmentation
container would be the deepest one. There was discussion
on trying to convey we're trying to get the deepest, but
no one had a good idea.
fantasai: We don't have any good options to fix this, though I
agree the current set is confusing.
<SteveZ> How about Break:Nearest
<fantasai> SteveZ, seems might be confusing with nearest box,
element, breakpoint, something else in a lateral
direction
Florian: One path is to say now that we're having more types of
fragmentation containers we can go through the use cases
and see if always and any are right or if we need to
change these things. It's not clear that these are the
best way to do things. The possibility to call out which
you want to break has been suggested a few times.
Florian: Maybe we go through the use cases and see what's best for
renaming.
fantasai: I think that's fair.
Florian: And while we do that include the things we haven't quite
finished like overflow fragments in the latest
incarnation.
fantasai: Yeah, as we do the thinking. One of the use cases is if
you break the column or the page depending on if I'm in
a column or a page.
fantasai: Although if you require a column break and all you have
is pages maybe you do that since a page is really just a
single column. The mixing of fragmentation contexts is
weird. I think we want named contexts, but we wanted to
defer that level for now.
<fantasai> until those mechanisms were more definite
Florian: I understand wanting to defer, but since the design is
not obviously the right one, it sounds worth doing.
Especially with regions and fragmenting the level of
nesting may change within the document and it becomes
more important to be able to name because you can't just
could third from the top.
Rossen: This is true and it's what we've been talking about, but
at level 1 we want to at least give the ability to break
at first fragmenting level which will let authors have
content into templates regardless of what the templates
are made out of. When there is content that wants to avoid
or break any fragmentainer, that's what the keyword is
intended to do.
Rossen: Yes, named breaks will be something we're working on for
another level.
Florian: What I'm trying to say is that, I don't want named breaks
now, but once we have named breaks, I'm not sure if we
still need 'any' or 'always', maybe one will be
unnecessary.
Rossen: Perhaps, but we don't want to stall the progress for now.
Named breaks are moving to level 4 and for this level we
have any.
Rossen: If anyone has any better names or wants to change the any
keyword you can respond to the e-mail or speak up now.
Otherwise we'll move on.
SteveZ: The problem I have with 'any' seems arbitrary. Like pick
any fragmentainer you're in and break it. I suggested
'nearest'.
Rossen: That's what I suggested to. I've suggested 'nearest' or
'closest' or 'first'. The way I think of the auto of
breaking, the element that is requesting to be broken or
not is looking inside out and it wants to declare its
preference for the first or nearest fragmentainer.
fantasai: What I'm afraid of with 'nearest' is if you have a
region with a fixed height and it's 1 1/2 pages worth.
If you're on the first page, the nearest break is the
page break, not fragmentation.
Florian: So in linear, not depth.
<bradk> 'Nearest-ancestor'?
fantasai: Yeah, I think that will be a point of confusion.
Rossen: I don't disagree.
fantasai: And 'deepest', it means break before the deepest element
in the tree, next isn't something they think of. This is
why I'm struggling to come up with something that
reflects what's going on.
SteveZ: Doesn't 'any' have the same problem?
fantasai: I agree it's ambiguous. But at least it's not specific
in a misleading way.
SteveZ: It's unspecific in a misleading way.
<Florian> closest-ancestor-fragmentainer
<bradk> closest-ancestor-or-self-fragmentainer
Rossen: Or we could drop this to level 4.
fantasai: I'm okay with that.
Rossen: Me too.
Florian: One alternative is just call it 'break'. When you think
of for and why loops, you break just one level.
Rossen: The analogy of loops isn't appropriate. You can break in
the parent loop. In fantasai's example you can break at
the page.
Florian: Yeah, loops don't nest that way.
Rossen: Right.
Rossen: I think the way I see it, we can live with 'any'. There is
a somewhat good use case for having 'any' or 'nearest' or
whatever we come up with. Or we can say this logic will be
solved by name breaks in level 4.
Florian: What was wrong with 'deepest'?
fantasai: It would imply a location deep in the element tree.
Authors don't have a concept of nested fragmentainers.
It's not fundamental enough in CSS it wouldn't do. Most
people want a page, column, or region break. There's no
nesting, it's just three different things in parallel.
Rossen: I agree with what you're saying. I don't think authors
will think of more than one level of nesting. No one
thinks their multi col will be printed and what happens
where there's fixed height.
fantasai: Most common is something just wants to break for the
next chapter and they don't care about what type. You'll
need named break for regions.
Florian: You'll want to say "break regions or columns" or "break
regions or pages". You have a set of things you want to
break into. You won't be completely agnostic about I
don't know how many things will be nested but I want a
specific break.
Rossen: It sounds like there wasn't much resistance for this to be
in level 4.
Rossen: Given that this is the only big outstanding issue, we
might have to think hard about this one.
<SteveZ> +1 for level 4
fantasai: Yeah, but we still have the problem of the always value
that's in multi col. I think there's a case of authors
just wanting a break and they don't care about the type.
That's basic.
fantasai: I don't know. I guess we should move to the next topic.
<SteveZ> I do not think "just Break Me" is clear if people have no
knowledge of the nesting
Florian: The only reason I don't want to move to level 4 is any
and always will have to named as a pair, so we should
have them together in the same level. They're a set and
if we define one and push the other to the next level,
we're locking ourselves in. Other than that I'm happy to
push back.
Florian: If we're stuck on 'always' anyway, sure, but if it's
still on the table I'm not sure.
Rossen: Some of the other proposals were always-any,
always-deepest, always-all
Rossen: That's another proposal on the table.
Florian: break one
<bradk> break: page region /* not column */
<Florian> break: something / break: everything
plinss: I'm not hearing us getting closer to a solution here.
plinss: Suggestions to make this go forward?
fantasai: I think push back to the mailing list for now.
plinss: Let's do that and come back when there's new info.
Percent resolution for abspos vs inflow grid items
--------------------------------------------------
Rossen: I believe this was waiting for Mozilla feedback, or was it
TabAtkins?
fantasai: This was waiting for the F2F because TabAtkins wanted to
reopen the whole thing.
Rossen: This was for abspos, not just the general resolution. If I
have a nested abspos item in a grid and that item happens
to be laid out inside the grid, how does it resolve.
Rossen: I believe we agreed it should be consistent and the abspos
will resolve based on the grid. For that issue, I don't
think there was push back by anyone, but we were waiting
on someone to okay it.
fantasai: I'm not sure I agree. If we revert to % being always
against the width there's not issue. If we keep to top
and bottom resolving against the height, then we have an
abspos element that's positioned against the grid, it
behaves like any other abspos element, just as if that
grid container was any other kind of container. The
expected behavior would be that the margins resolve the
same as any other abspos context and that means going
against width.
Rossen: I don't buy it. It's saying if I have a grid item with
nothing spec on it, it's the same as if the div was inside
a block.
* astearns this sounds like something for the face to face as well
fantasai: Is an abspos element considered to be affected by the
layout of the containment block, or is abspos a layout
mode?
Rossen: It's the containing block.
fantasai: It's just a rectangle. It's defined that was in CSS2.1
Rossen: I know the definition, but as soon as we talk about grid
and abspos items can be dependent on grid it's contextual.
For level 3 and above it's more than a rectangle and it
better be more or you're stuck in the 90s.
* bkardell hmm, it seems like abspos is a layout mode
conceptually to me :(
Florian: What I'm hearing is that this is complex question and
touches on what TabAtkins wanted to reopen.
Rossen: There's nothing complicated about question.
Rossen: If we're talking about abspos items only, that issue is
very straightforward. If TabAtkins wants to reopen the %
issue, we can do that at the F2F.
Rossen: This is about items in a grid and has nothing to do with
the bigger decision about percentages.
* fantasai does not believe it is straightforward
* bkardell believes fantasai in that it does not seem
straightforward as it is presented as
* antonp thinks the containing block should always be a rectangle;
and that abspos is probably its own layout mode that's
independent of the layout mode of its ancestors
* dbaron agrees that containing block should be a box associated
with an element rather than just a rectangle, but
otherwise isn't really following
* tantek is trying to remember very old conversations about
containing block
Rossen: So, what's going on? Are we discussing it or dropping by
not discussing it.
fantasai: Well.
fantasai: The reason it has to do with the other issue, if we
revert on the other issue, this becomes moot. Why it's
not straightforward is you and other people have
different conceptual ideas of abspos and until we decide
if it's its own layout mode or not, we have to solve
that conceptual problem before we can tackle this.
<Florian> +1 to fantasai
fantasai: So I don't think it's as straight forward as you think
it is.
Rossen: So do we want to leave it to the F2F?
fantasai: I think that's a better idea.
Rossen: Okay. I'm not the one who put the item on.
fantasai: The chairs put it on after we decided last week to defer.
plinss: Let's defer to the F2F.
plinss: Next is grid OM issue
fantasai: I said that this was answered on the ML. Did you not get
that e-mail?
plinss: I didn't. We can skip.
<fantasai> email :
https://lists.w3.org/Archives/Public/www-style/2015Jul/0436.html
Interaction between overflow-x and -y
-------------------------------------
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Jul/0432.html
[From the e-mail, the list options are:
A) "overflow: clip" is a paint only operation, it does not (on
its own) create a BFC, and if "contain" is not "paint", you
can have "overflow-x:clip" in one dimension and
"overflow-y:visible" (and vice versa). Amend the definition
of "resize" and "text-overflow" (and anything else that
depends on "overflow") to deal with the new possibility of
being visible in one dimension only.
B) Rename to "overflow: hidden no-scroll". It creates a BFC. If
you specify it in one dimension only and leave the other
visible, the visible one computes to auto.
C) Don't introduce a new value to overflow, make "contain:paint"
cause "overflow:visible" to compute to "overflow:hidden", and
implement heuristics to detect when browsers should avoid
allocating the resources needed to do the scrolling. ]
Florian: It would be good to have TabAtkins. We can maybe talk a
bit without him.
Florian: Trying to summarize the current status. We have
contain: paint which is to enable optimizations at the
paint level. What it wants to do is establish a
containing block. Also, to do clipping of anything that
might overflow.
Florian: And earlier version called this magic clipping. There are
things that depend on this going through the overflow
property. Text overflow and resize only work if overflow
is not visible. TabAtkins and I proposed overflow: clip
that does the same as hidden, but doesn't scroll. People
said we should call it something else or we do something
similar to clip path.
<tantek> overflow and clip are so confusing both in name
(including values) and function that I have to look it up
every time. This despite having implemented it in IE5/Mac.
<tantek> it's one of the worst parts of CSS 2 legacy.
Florian: Another point that was raised was if we go hidden
no-scroll is it needed? The browser can perhaps just
detect that the scrolling isn't used and skip it to be
more efficient. This is akin to will-change where if we
assume a smart enough browser it can be done, but it
doesn't seem like they'll be smart enough soon.
Florian: We can say overflow: clip doesn't establish a BFC and you
can have it only in one direction for contain: paint this
may work, but I'm not happy about it because there are
parts of CSS that assumes it's visible or there's a BFC.
Florian: If a re-sizable thing isn't a BFC, suddenly margins
collapse. It's a possibility.
Florian: The other option, B, is to rename it and it's the same as
hidden, but you don't get to scroll. C is contain: paint
invokes the regular overflow hidden and browsers just
need to get smart.
Florian: I don't like A much, but if all browsers can convince
each other to do the heuristic, C is good. TabAtkins
doesn't think that's the case and he represents a
browser, so if C won't do, I think B is what we should do.
Florian: There's some side questions, but that's the meat of the
problem.
* fantasai thinks that A makes the most sense
smfr: What if you said that when contain: paint, it implies
overflow: hidden, but in that scenario scrolling is
disallowed. It would prevent scrolling and imply overflow:
hidden.
Florian: I guess it's okay unless you want scrolling because then
you can't access it. Contain: paint provides other
optimizations. If it's off screen, you know you don't
have to paint so you can skip it. Say maybe you want it
for that effect, but you're still interested in scrolling.
smfr: Are you only concerned about where contain: paint and
overflow: hidden are on the same element, or when the hidden
is inside the contain?
Florian: Not particularly the second. But overflow: hidden
no-scroll allows for some optimized situations. contain:
paint should be the superset of what you can get through
overflow plus the rest so you have one switch that can
turn it all on and it's fast. For speed it does work, but
it reduces some things. Maybe it's a trade off and you
can be fast or you can scroll.
* bradk likes smfr's idea. Seems simpler.
fantasai: I'm a little confused as to why A is so bad.
fantasai: Not establishing a BFC is straight forward.
Florian: On its own yes. But has the design of the resize property
considered if it's fine to not be a BFC? Design hasn't
considered it. So maybe that's okay for resize until you
resize to 0. It's not obvious author-wise.
fantasai: Resize right now only applies to elements with overflow
not visible. So you would change it to also do clip.
It's the same as visible and the only difference is you
have this clip path and you may also want text overflow
apply as an exception.
Florian: That's why I don't like A. It could work, but you have to
get into these little details. Are there other parts of
other specs we've forgotten? There are these ripple
effects and I'm not sure we have it under control.
fantasai: I don't think there's many. text-overflow is this weird
case because compat issues. I don't think there's that
big of a problem with this kind of definition and I
don't think the others are less complex.
Florian: If that's all, it's not that bad. The other weird thing
with A for not establish a BFC...I'm okay with an
overflow: clip that doesn't effect margin collapsing, but
that invisible floats can poke through feels weirder.
<tantek> "invisible floats poking through" sounds very weird indeed
Florian: I'm not objecting to A, it just feels weird.
Rossen: It's definitely weird.
fantasai: Yeah, that does seem weird.
dbaron: We offer a whole bunch of other ways to do visual clipping.
clip path, clip to some degree.
fantasai: I don't have an objection either way, I just wanted to
understand.
Florian: Between B and C, it's a matter of what browsers can do.
* fantasai is really interested in what dbaron thinks of all this
Rossen: Who wants A? Was that Mozilla?
dbaron: I'd kind of like to see A. There are people that want to
clip without the BFC.
Florian: But wouldn't that be more appropriate to explore through
clip and clip path instead of overflow?
dbaron: Maybe.
Florian: The play devil's advocate, there is...one nice thing
about A is that it opens the possibility to do overflow-x
clip, ellipsis, and overflow-y visible. That seems useful
regardless of contain: paint. That's how I would justify
A.
Florian: We previously resolved not to have that, so maybe it's
not that strong a use case.
smfr: I'm not convinced clipping only one axis is that useful and
it would add to impl complexity.
<gregwhitworth> I agree with smfr
Rossen: So are we leaning B?
Florian: I think you and smfr were against B and C.
Rossen: We are not for A. Let's start there.
Florian: So do we drop A?
plinss: Anyone advocating for A?
plinss: Okay, we'll ignore A.
<fantasai> I think the main problem with A) is that contain: paint
won't be able to use it, if floats outside of the
element are not clipped
<fantasai> (clipped layoutwise, I mean)
<fantasai> (in addition to paintwise)
* fantasai kinda prefers calling it overflow: clip anyway
Florian: I think TabAtkins wants B. If everyone else wants B we
can resolve. If not we need TabAtkins.
Rossen: I'm okay with B.
Rossen: B is the one that creates a BFC?
Florian: You have a special value of overflow that creates a BFC
and you can't scroll.
smfr: Just like overflow: hidden, but you can't programmaticly
scroll.
Florian: Yes.
smfr: It's making assumptions about impl details, but I can live
with B.
Rossen: B is more explicit for the users. It's declaring this
won't scroll no matter what. If you're hidden is already
declared. So B makes sense.
Florian: Since you both pushed for C before, I think if you're
okay with B we can resolve.
Rossen: We can live with B. smfr?
smfr: I feel like B is sort of making up for a historical mistake.
We're adding complexity because we've got a previous mistake
which is why I feel C is better.
Rossen: I think you're right, but we are where we are and there
are use cases where people want to prevent scrolling and
they don't have that ability. They're making mistakes and
now we're giving them an explicit way to say it's hidden
because I don't want to scroll.
smfr: I can live with B.
Rossen: One bikeshed on B. Do we need the extra value, or can we
make this an optional value to hidden?
Florian: It's hidden no-scroll
Rossen: I mistakenly heard it as hidden-no-scroll
ChrisLilley: Yes, I wasn't clear on that.
Florian: I wanted hidden no-scroll. I think it was minuted as
hidden-no-scroll last time which might be the confusion.
It's hidden no-scroll.
Rossen: Okay, then we have no problem.
smfr: Then if we use it on one axis, the other computes to auto?
Florian: Yeah.
fantasai: I think it would be easier to, as an author, pick one of
these four options instead of one of these three and
maybe a flag.
<smfr> yeah what does overflow: scroll no-scroll do?
Rossen: Is that true? I can see cases where people may or may not
want to allow you to scroll the content given some
parameters.
fantasai: So you're suggesting we have no-scroll as an option on
scroll?
Rossen: To anything that's scrollable.
Florian: To me it's a flag on hidden only.
Rossen: I'm trying to figure out if there are other use cases we
could cover. I can see forms where based on some form
validation you might not want to let people scroll down.
fantasai: It's an interesting point, but I'd like to keep to a
single value property unless there's a really compelling
reason.
Florian: The space instead of hyphen was to make it clear that
it's a variant.
fantasai: I'm not sure that tie in is necessary. Anything other
than visible makes a BFC.
Florian: Clip confused people, so I'd rather not that.
fantasai: So another word. But it doesn't have to be connected to
hidden. It's just here's your four values, pick one. It
doesn't have to look like an extended variant. Authors
might want to switch from hidden to this.
<ChrisLilley> overflow: (push) and overflow (pop)
Florian: So let's pick option B, defer naming to editors, everyone
complains if we pick something bad.
RESOLVED: pick option B behavior, defer naming to editors,
everyone complains if they pick something bad
Florian: Another question is if you set a value other than visible
on one axis and leave the other unset and then you set
contain: paint, the rules of computed value on overflow,
if you have visible in one direction and not the other
it's visible. We have different things trying to change
the visible, but which acts first? I'd say it goes to
auto and if the authors want something we can make it
explicit.
plinss: We're past the hour.
fantasai: If anyone wants to do an apt share for Paris tell me now
so I can find space for the number of people.
Florian: I have 2 answers including mine. Is that what you have?
fantasai: Yeah.
plinss: Thanks everyone. Talk to you next week.
<Florian> anybody interested in a mini bikeshed? "hidden
no-scroll" "hidden-no-scroll" "none" "cut"
* fantasai is against the first two for being too damn long to type
<bradk> hidden-stuck
<Florian> the second one looks like a long name because we
couldn't find a name, so I don't like it. The first one,
despite being almost the same, looks like a short name
with a switch, and I'm ok with that. But yeah, it's
still long.
<Florian> "none" might be fine. It's even shorter than hidden,
which means people might start using it just to save
some typing and didn't actually need the scrolling.
<Florian> (saving resources for everybody)
<fantasai> I'd prefer a word that captures the fact that stuff is
not visible if it overflows
<fantasai> none just means "there is no overflow"
<fantasai> Does that mean it got clipped? Or does that mean we
made the box bigger so that it doesn't overflow? ;)
<Florian> made the font smaller
<fantasai> :)
<Florian> or the author less verbose
<bradk> 'none' is cool, but will confuse new learners, who have to
try to understand the difference between that and 'hidden'.
<fantasai> 'discard'?
<antonp> fwiw I quite like "none"
<Florian> new learners would pick none, which is good, since they
almost never want the scroll part of hidden.
<bradk> But I guess that's a problem regardless.
<antonp> "hidden" quite nicely describes the current behaviour I
think, since it really is there, but hidden
<Florian> discard might be ok, but I'm worried about confusion
with the fragmentation of overflow property/values
<bradk> So far, I like 'none' best
<antonp> None implies it's not there, which indeed it isn't, to
all intents and purposes.
<fantasai> actually, is that true?
<fantasai> if there are two lines of content
<fantasai> and they are too long to fit
<fantasai> and so get clipped by this value
<fantasai> and I select from the first to the middle of the second
<fantasai> have I selected the text that is clipped?
<fantasai> Will it get copied?
<fantasai> I think it will
<antonp> hmm, ok, good point
<fantasai> So discard isn't good either
* fantasai really thinks clip is the best
* fantasai can't remember why it's bad
<Florian> that rules out discard, but maybe not none (although
your other concern stays)
<Florian> clip is what I started with, but then half the WG got
onto "but then why doesn't it do the same as the clip
property, and skip establishing a BFC". Or at least that
was how I understood the feedback
<Florian> I was happy with clip until it seemed to confuse people.
* antonp wonders how clip (property) behaves with regard to
fantasai's select-and-copy use case
<fantasai> no effect
<fantasai> it's just a painting level thing
<Florian> overflow: this-is-not-the-content-you-re-looking-for
<Florian> it's still there, but you don't notice it
<antonp> ok, that's what I imagined
<Florian> (sorry)
<fantasai> Florian: Were people actually confused, or was it just
"but this is another possible interpretation that we
need to consider"
<fantasai> ?
<Florian> fantasai: not sure.
<fantasai> Florian: Particularly given Mozilla implements the A)
behavior, I think any name you'd choose would bring up
the same question
<Florian> If we go for clip, that's less work for me, since the
spec is already that way :) But I kind of like 'none'
too now.
<Florian> in casual talk, does "you should clip this element" mean
"overflow:clip" or "clip:border-box" (or something like
that)?
<fantasai> Probably anything that has a clipping effect
<Florian> I meant: once we have both overflow:clip and
clip-path:border-box, when 2 css designers talk to
eachother, they cannot use word clip without being
ambiguous.
<Florian> I'll sleep on it, ping Tab (because of contain) and
dbaron (co-editor), and see where that takes us. Maybe
we'll stick with clip
<fantasai> Florian: They could also mean 'clip' or 'mask' or
'overflow: hidden'. They all clip
<Florian> dinner time, see you all
<fantasai> kk, laters
Received on Thursday, 30 July 2015 11:48:22 UTC