- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 9 Jul 2015 08:11:20 -0400
- To: www-style@w3.org
Paris F2F
---------
- Everyone was okay with having some overlap time with the SVG WG
during the Paris F2F instead of during TPAC.
Using an images/ Folder for Specs
---------------------------------
- RESOLVED: keep images and an images/ folder and source files in a
source/ folder for each spec
Clarification on percent margin/padding
---------------------------------------
- This issue was editorial and will be addressed by the editors
Logical Values for caption-side
-------------------------------
- RESOLVED: add block-start-outside and block-end-outside
overflow: clip and BFCs
-----------------------
- One of the blockers for the conversation was the use of the word
'clip' when it really was a property to just do
overflow: hidden, but not allow scrolling. If the property is
re-named a main objection will be removed.
- hidden-no-scroll was the new name used on the call.
- A larger issue as to if this is solving an important problem was
also raised. One side was that this is along the same lines as
will-change that allows authors to indicate intentions in
order to speed up the browser. However, the same argument that
will-change was fixing an implementor issue can also be
applied to overflow: clip.
- Florian will write an e-mail summary of the conversation and the
options moving forward to continue the conversation forward
with input from those that weren't on the telecon.
Variants of pre-wrap and longhands of the white-space property
--------------------------------------------------------------
- The third option in Florian's list of suggestions (available
here: https://lists.w3.org/Archives/Public/www-style/2015Jun/0099.html)
was discovered not to be a potential solution.
- It was instead replaced by eliminating the white-space longhands
that are causing the problem.
- Discussion will continue on the list.
bikeshed user-select: element
-----------------------------
- This conversation will wait a week so that people can review the
history of this property.
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Alex Critchfield
Simon Fraser
Daniel Glazman
Koji Ishii
Dael Jackson
Brad Kemper
Chris Lilley
Peter Linss
Myles Maxfield
Anton Prowse
Florian Rivoal
Simon Sapin
Hyojin Song
Alan Stearns
Lea Verou
Johannes Wilm
Regrets:
Tab Atkins
Sanja Bonic
Edward O'Connor
Greg Whitworth
scribe: dael
plinss: Anything to add?
Florian: Topics 6, 7, and 8 are related and I prefer 7 before 6.
Paris F2F
---------
plinss: I did have one request from Cameron. Looks like SVG
meeting isn't going to meet at TPAC and they're looking at
co-locating with us in Paris and were hoping they could
spend time with us in Paris.
ChrisL: When in Paris?
Rossen: We decided to combine SVG and CSS. SVG will start Monday
or maybe Sunday and we'll overlap two days with CSS. In
that way we can do a FX joint meeting either the first or
second day of the CSS meeting.
Rossen: If there are issues that require some members we can go
back and forth between rooms.
Rossen: Basically, they'll overlap for two days.
Florian: Depending on agenda, I don't mind doing it during the
overlap, but I do mind before.
Rossen: I don't believe that was the request.
Rossen: The request was for a regular CSS date.
plinss: I'm not hearing objections so I'll send a thumbs up.
Rossen: We can provision a half day and if more is needed everyone
is in the same building so we should be able to facilitate
as we go.
plinss: Right. We can factor that into the agenda.
Rossen: There's a number of topics pushed away for joint
discussion. And since there's too many members with TPAC
conflicts they decided to cancel that meeting.
Using an images/ Folder for Specs
---------------------------------
plinss: TabAtkins isn't here, but he sent an e-mail with the
proposal.
fantasai: Sounds good to me.
Florian: It's all images in a sub folder of each spec, not a joint
folder, right?
plinss: Yes.
Florian: That I'm okay with.
smfr: I like the idea and did it for transforms.
smfr: There was question about where to put files generated by
images and I'd prefer them in a separate folder.
astearns: Things should be in sub folders, that's what we should
go with.
Rossen: The way I read the request is he was requesting a single
folder for all of them.
Florian: It's one per spec.
<astearns> and we shouldn't dictate folder structure
fantasai: Each spec has a folder for where the files and and the
images for the spec would go in there.
Rossen: And this is more optimal than one images folder for all
the specs and if a spec requires something special...
fantasai: We have:
<fantasai> css-break/Overview.bs
<fantasai> css-break/Overview.html
<fantasai> css-break/images/
<fantasai> css-break/images/diagram.png
fantasai: And all the stuff goes inside images.
Florian: We don't share images across specs.
plinss: And a shared folder would create publication problems.
ChrisL: And if something changes you need to work out dependencies.
Florian: Do the source files for the images go in there or do we
use a sub folder?
ChrisL: I prefer separate. And for publication it makes it easier
to have separate.
* fantasai prefers keeping sources in the same folder, easier to
see which file you're supposed to edit when working
with them images
* fantasai is sympathetic to concerns wrt publishing, though
smfr: How does publishing choose which files?
ChrisL: On the new system you send a manifest file that lists all
the directories and files in that. Old way someone made
the choice.
Florian: My small use case for separate images and source is what
I did for CSS 3 there were a bunch of images and not all
were used and it makes it a lot easier if the images
supposed to be used are in one place, but that's a small
thing.
RESOLVED: keep images and an images/ folder and source files in a
source/ folder for each spec
dbaron: But it goes in a sub directory?
plinss: bikeshed source file, see where they are. This is just
files to generate images if any.
<dbaron> I don't think "source/" was a name to be used for image
sources...
Percentage resolution for abspos vs inflow grid items
-----------------------------------------------------
Florian: Didn't we do that?
fantasai: And we need TabAtkins
Clarification on percent margin/padding
---------------------------------------
Rossen: This is editorial. I don't think it requires much group
discussion.
Rossen: Basically someone reading the spec was confused by the
current text that says margins and paddings resolve their
percent values from their...what was the current text...
from their respective sizes or something like that. It
sounds like they would resolve percent from themselves.
Rossen: It's editorial to show they resolve from the width or
height of the block.
plinss: We'll let you take care of that one.
Grid issues
-----------
Rossen: Who has this one?
plinss: There were some from fantasai and gregwhitworth had one.
Rossen: For gregwhitworths's he's on vacation.
Rossen: I don't have the ability to do those. We can push them to
the end of the call and by then I might be in the office.
plinss: We'll defer those.
Logical Values for caption-side
-------------------------------
<dael> https://lists.w3.org/Archives/Public/www-style/2015Jul/0004.html
fantasai: We have 2 values of caption-side that didn't have
logical equivalents. In the spec and those are
top-outside and bottom-outside and the proposals are
block-start-outside and block-end-outside.
Rossen: Let's start with those and if we rename we'll do
everything. Being consistent with the current ones sounds
good.
plinss: Other opinions?
<glazou> +1
smfr: What does outside mean in this context; source? stuff for
generating images? I would rather leave it up to editor
choice.
fantasai: The model for table captions in CSS 2 is the table
caption is a block whose containing block is the width
of the table's containing block. In implementation
captions were constrained to the size of the table
itself. In CSS 2.1 we changed the definition so that
that's how it behaved.
fantasai: Because you often want the old behavior we said there
would be top and bottom values that would hold the
behavior. Mozilla had implemented those as per spec and
since they have that and they're implementing logical
equivalents they needed logical values for those that
don't exist anywhere but note.
smfr: So it's in terms of containment, not left page, right page.
fantasai: Yes, it's about the table, not paging.
Rossen: What module is that in?
fantasai: caption-side values are in CSS 2.1 in a note.
fantasai: And we have the logical equivalents in writing-mode.
Rossen: Thank you.
<fantasai> The model for table captions in CSS2.0 was the table
caption was a block whose containing block was the
table's containing block.
<fantasai> However, in implementations, captions were constrained
to the size of the table itself.
plinss: It sounds like people are okay with it.
RESOLVED: add block-start-outside and block-end-outside
overflow: clip and BFCs
-----------------------
<dael> https://lists.w3.org/Archives/Public/www-style/2015Jul/0013.html
Florian: In relation with containment and paint containment, we
added a value to overflow that's 'clip'. It's the same as
'hidden', but you can't scroll even programmatically.
Very often that's what authors want and if they can say
that it allows browsers to be more efficient.
Florian: Mozilla has a slightly different thing. Every value of
overflow other than visible makes the elements create a
BFC.
Florian: Mozilla's doesn't do that.
Florian: Before we go further I thought we should consider that
and if we should align. I think it's odd, but it's what
they do.
Rossen: This would complicate the float algorithm quite a bit
because if I have floats that extend past the bounds of
the clipping element, it means they're bound for the
purposes of line layout will need to be considered for
visual clipping.
Rossen: That sounds weird.
dbaron: That's not what Mozilla's value does.
dbaron: This is how we did overflow: hidden before it was clear
what it did. What we do is just visual clipping, it's not
layout change.
dbaron: It's a lot like clip, but it applies to more than abspos
elements.
Rossen: So layout would have been taken account like it's visible
and the clipping is render time only behavior?
dbaron: Yes.
Florian: So for historical reasons, I see how you ended up there,
but do you want to maintain it?
<vollick> Is this related to contain:paint?
<vollick> I.e., is overflow:clip similar to overflow:hidden +
contain:paint?
Rossen: I question the usefulness.
dbaron: Its been useful as a lighter weight variant of clipping.
Rossen: What makes it heavy weight?
dbaron: You need to be able to allow scrolling. In our
implementation some of that is heavy.
Florian: That's why overflow: clip is supposed to be different.
It's the same as hidden, but you don't have the scrolling.
Rossen: It's going to be a different behavior because all the
floats inside the clipping element, but adding clip all
the floats won't affect the layout outside. If you toggle
back and forth with the clip you have to re-layout.
Florian: That's the same as hidden.
Rossen: Yeah, in that respect yes. In the way dbaron described it
you wouldn't have to do anything, it's just visual.
Florian: In terms of run time costs, switching to my clip is
higher cost than Mozilla's. But in terms of
implementation you have it already because you have
hidden.
Rossen: In terms of implementation cost for us, if we pursue one
of the other there won't be that much difference, I don't
think. It's allowing...um...
Florian: I question the usefulness of hidden floats going outside
and change the layout.
Rossen: That's what I have a problem with. If there's a float to
the bottom and I clip it the stuff at the bottom will re-
layout and that's weird.
dbaron: It's also weird to design things to be more expensive just
because of floats which we do a lot.
Rossen: But we can't just ignore them, right?
fantasai: Keep in mind that we do now have a switch for creating a
block formatting context group. A lot of overflow is to
make the BFC and you can do that now explicitly. Right
now you can't say I just want to clip as easily.
Florian: What's the use case for clipping without a BFC?
fantasai: Maybe you don't have floats, just margin collapsing, and
you don't want to change the margin collapsing behavior.
Rossen: It sounds again like we're oversimplifying once we toss
the float out of the picture.
Rossen: dbaron, in your implementation I'm assuming the only
things you're doing is constraining the key region for the
rendered sub tree?
dbaron: I think so, yes.
Florian: One of the goals for this value, just like the other
non-visible values you should be able to use it with the
stuff that requires overflow to be non-visible.
fantasai: That should be fine. Right now we don't have a way of
saying I want to clip only in this dimension.
fantasai: This would allow you to combine, you could have hidden
overflow in the y and visible in the x, we don't have
that.
Rossen: I would argue we should extend clip and define it so that
it applies to everything and not piggyback on overflow.
dbaron: I think if we want overflow: visible in one direction and
not the other, it makes sense to not make a BFC. I suspect
webcompat will let us not extend and we'd need something
new.
<tantek> agreed with dbaron about clip compat
Rossen: Do you know how much of a compat issue this is for you?
Because we haven't done this.
dbaron: We haven't implemented and I don't think anyone has. Its
been out there for years so I think there will be breakage.
fantasai: 'clip' could apply to more than abspos if you made the
rect value not apply.
fantasai: The rect notation is very awkward so the other ways of
spec clip paths are better and if we had those they
could apply to all.
Rossen: So if we're talking about clipping, let's make it part of
clipping not overflow.
Florian: Stepping back, one of the reasons of introducing this,
when you do contain: paint it would do a number of things
including something like overflow: clip but it wouldn't
go through the overflow property, so you couldn't have
resize apply to that. Unless you turn it to hidden or
auto, but that causes memory allocation to go up. Having
contain: paint do overflow :clip through the overflow
property is part of the justification for having this.
Florian: If we have the ability to be overflow-x: visible and
overflow: clip the resize property doesn't make sense. We
used to have a note that this is an oops and we need to
fix it, but we removed it because we didn't think it
would happen.
Rossen: Do you think this would change if we define it on the clip
rather than the overflow?
Rossen: I have overflow: visible in both directions and have
clip: bottom...
Florian: There would be a compat issue if resize starts to work
when overflow is visible. There may be things that
depend on it not applying.
Florian: We could define to do something sensible when you have
visible only in one direction. That could be an expansion
to the spec.
Florian: If you say resize in both directions, but only one is
visible, the other is clip, then I don't know.
Florian: It's not a case that's been possible before. Maybe you
can do in both directions if it's something other than
visual. It's a bit more complex than saying it's the same
as hidden without scrolling.
Florian: To do as fantasai said, this would be possible.
Rossen: My pushback is I'd prefer it to be part of clipping. The
overflow has already happened. If the floats that are
overflowing have already affected the contents, it means
it happened.
Florian: I think it's going to be a problem to go through clip
because if you're trying to contain: paint and resize.
You do contain: paint because you don't want a large
buffer. If you're in overflow: visible you can't have the
resize apply. And then you have to flip and you end up
with the buffer and possibly scroll bars.
fantasai: I think a more common case is wanting to have text
overflow apply and the ellipsis set.
Florian: Yes. Same problem.
Rossen: This is a use case for overflow: hidden
Florian: Yes, but it brings in what you didn't want, scrolling.
Rossen: You're describing to me having an additional scroll/no
scroll keyword to overflow: hidden...
Florian: Yes, I'm just calling it clip. I'm happy to call it
hidden-no-scroll except that it's long.
Rossen: And that comes with all the BFC-ness etc. It basically
clips on both sides.
Florian: Yes.
Florian: So if we rename you find it more acceptable and leaves
'clip' for another property?
Rossen: Correct.
Florian: I'm okay with that.
Rossen: Are you defined those as part of UI4?
Florian: Overflow spec.
Rossen: Oh, okay,
<tantek> yes we decided a while ago to move overflow properties
from UI to another spec, except text-overflow.
Florian: And in containment when it comes to computed value of
both properties.
Rossen: Right, right, okay.
Florian: I think Rossen and I are on the same page.
fantasai: I'm a bit less sure.
Rossen: What if you did the changes and we can discuss more on the
list or at a call?
Florian: I'm okay with that. I'm not editing clip property's spec
so the part that is done through the clip property
someone else will need to do the edits. I'm happy writing
something. For overflow I can spec and discuss again.
Rossen: Cool.
smfr: Is it accurate that you're suggesting a new hidden-no-scroll
because for some UA hidden makes you scroll and allocate
resources?
smfr: I'd argue that's an implementor issue. If the hidden is
never scrolled, the UA doesn't have to allocate resources.
Florian: It's the same nature as the will-change. You could get
around it, but in practice people don't. So let authors
be explicit we have a value.
Rossen: I'm fully...I agree with smfr. If we're talking about the
heuristic, you would create all the scroll handlers and
objects the first time you request to scroll from script
for overflow: hidden. Going into the behavior where users
explicitly want to prevent scroll, like you're doing
layout behind the scenes, for that I can see a better
argument.
Rossen: What I'm hearing is the motivation is the performance. And
a new value for that is overkill
Florian: I understand your point, but why is it that having a new
value for this isn't good, but will-change is fine? They
are the same kind of thing.
Rossen: I've never said I was fine with will-change.
Florian: For me, I'm not the biggest fan, but if we're going in
that direction this makes equal sense.
Rossen: But piggybacking on...I'd prefer to follow the good
examples.
<vollick> I tend to agree with smfr as well.
Rossen: Back to your topic, do you...I don't know where we stand.
Do we want to discuss more on the ML when TabAtkins can
contribute?
Florian: I think we have two reasonable ways forward. One is to
have hidden-no-scroll and contain: paint can invoke that
or it just invokes hidden and you can scroll. I'm okay
with both. I'm not okay with contain: paint doing the
magic clip and it's not accessible manually
<fantasai> +1 to what florian just said
Florian: If contain: paint will do something to overflow, I want
it to affect overflow.
smfr: Can it not select clip-path?
Florian: Then you can't use the resize which depends on it not
being visible.
smfr: It allows resize?
Florian: contain: paint does not in itself prevent resize. The
thing is if it is just like overflow except not through
that property then that it's not through there means you
have to set overflow to get the things that depend on
that and if that affects speed it's no good.
Florian: So I think given the situation we're in it's too early to
write a spec, but I can write a new summary that says can
we have good enough heuristics and is this important
enough.
Florian: And if I'm missing something, you can reply to that
e-mail.
Florian: Does that sounds like a decent path forward?
Rossen: Sounds good.
smfr: I think so.
ACTION Florian write a summary e-mail about the discussion on
overflow: clip to move the conversation forward
<trackbot> Created ACTION-701
<vollick> Fighting with webex a bit. It feels like the efficiency
of overflow:hidden should, as smfr said, be a UA concern.
If we want a will-change style hint to say that we won't
scroll, could we tie this hint to will-change explicitly?
<tantek> ooh good question. is there an existing table we can use
and extend?
Variants of pre-wrap and longhands of the white-space property
--------------------------------------------------------------
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Jun/0099.html
<tantek> pre-wrap is one of my favorite CSS features :)
Florian: At the F2F we discussed changing pre-wrap and allowing
some of the current implementations in through
pre-wrap-auto
Florian: We also said in level 4 we would add pre-wrap-trim
Florian: We're explaining these in terms of white space, but in
level 4 of text white-space is a short hand and I'm not
sure how to split these between the longhands.
Florian: That's what this mail is about.
Florian: The longhands are text-space-collapse and text-wrap. One
option is to say text-space-collapse is the weird one. Or
we can go the other way around and say that text-space-
collapse is normal and text-wrap is weird.
Florian: I can see a lot of options and I'm not sure how to
proceed. If anyone has a feeling on how to split these
I'd appreciate input.
plinss: Anyone have anything?
Florian: I can be more specific, but I'm not sure it's easy to
think through by listening.
Florian: I have one question. This white space property now that
it's a long hand: is text-space-trim a longhand of that?
fantasai: I can't because it doesn't inherit.
Florian: Okay. That means option 3 in my e-mail is eliminated.
Florian: This pre-wrap-auto and trim are difficult because
wrapping and collapsing aren't entirely orthogonal.
That's why it's hard to say on which side of the
longhand.
fantasai: We could give up on the longhand?
Florian: That's the new option 3.
Florian: I can define options 1 and 2, but it feels weird. I'm not
sure of how the implementation is actually done, but I
think it's multiple stages and when you think of it as
stages the property can influence multiple stages. If you
don't care about stages, I can describe it and I have a
preference.
Florian: I think if fantasai can reply to my mail, if we can agree
we can ask the group it it's fine.
fantasai: It looks like a situation with no good option, but okay.
Florian: Okay. You have the URL, we can move forward.
Florian: I'm happy to spec both, but I'd like an opinion on which
way.
plinss: Okay.
bikeshed user-select: element
-----------------------------
Florian: It had this name, element, for no longer relevant history.
The behavior IE and everyone else has in text areas. If
you select within the element you can't select outside
the element. It's strange. I'd rather a new name. Its
compat risk is much smaller than other values so I think
we can rename.
Florian: I'd like 'contain'. Is that okay?
smfr: webkit implements this. The use case we had is we wanted an
element to select atomically. Our interest was outside-in
selection.
Florian: Atomic selection is something we have and it's
user-select: all
smfr: Okay, maybe I'm mis-remembering.
tantek: But you're right, that was the original intent, it's just
not needed.
Florian: And I think it was originally more complicated, like
selecting one and not several elements in a drop down
which is a different kind of selection.
* fantasai is pretty confused at this point
Rossen: I honestly don't remember the history.
Rossen: If we're okay to wait for next week so I can discuss this
and look back, I'd prefer to do that.
Rossen: Is that okay?
Florian: Yea.
plinss: We'll defer then. That's the top of the hour.
<glazou> bye
plinss: I'll be gone the next two weeks at F2Fs. Try not to have
too much fun without me.
Follow-up conversation on IRC about user-select: element
-----------------------------
<Florian> user-select (way back when) used to do several things.
Selection as we mean it today was one, but deciding
whether you can pick only one (like radio buttons) or
several (like checkboxes) in form controls was another
goal. radio buttons was called "element" and checkboxes
was called "elements"
<Florian> this was also supposed to apply to dropdowns
<tantek> Florian, also list view <select> elements
<tantek> where you could either select *one* <option> inside, or
multiple <option>s inside
<Florian> indeed.
<tantek> the point was to be able to rebuild that behavior out of
any elements
<tantek> rather, to be able to specify that behavior via UA
stylesheet
<tantek> rather than HTML magic
<tantek> on selection/option/input
<Florian> The modern incarnation of user-select does none of this,
but the "element" name has been repurposed to something
else. The something else is a useful thing, but the name
"element" is not a good match for it.
<Florian> for what the property and value do now, I'd rather call
it contain. Element is confusing, as evidenced by smfr,
who thought it meant "select the whole element" (which
is what the "all" value does).
<tantek> no smfr was right
<tantek> it's just that you two disagreed on outside-in aspects vs.
inside-out aspects
<tantek> or had different assumptions thereof
<Florian> well, smfr was right that it is one of the things this
value used to do, but he was wrong in that the value
webkit implemented to do atomic selection is not this
one.
<tantek> user-select was always intended to affect how selection
of stuff *inside* the element worked
<tantek> but seems to be have been re-interpreted as how selection
of the element itself works in its parent context
<tantek> "all" is atomic on the outside. element / elements is
atomic on the inside.
<tantek> they're both "atomic" selection variants
<TabAtkins> ...lolwut (re user-select being used to do
radio/checkbox)
<TabAtkins> That's nowhere near sufficient to model them. I know,
I wrote the spec to do so.
<Florian> element in the old spec was that. element as currently
shipped by microsoft (and the css-ui-4 spec follows that)
is not.
<Florian> The new incarnation of element is not about atomicity.
It simply says that a selection that starts inside an
element may not escape it. but you can still select only
part of that element.
<Florian> I am not debating whether or not the old version of
user-select matches this model, since nobody is
implementing (or planing to implement) the old version
of user-select.
Received on Thursday, 9 July 2015 12:12:19 UTC