- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 8 Oct 2015 07:32:42 -0400
- To: www-style@w3.org
TPAC
----
- Everyone was reminded to add items to the wiki for TPAC
conversation.
- The Houdini task force will meet on the Thursday of TPAC. They
may also hold a breakout session on the plenary day depending
on if there are proposals for specific topics and/or meet on
Friday if they need more time.
Snapshot
--------
- RESOLVED: Adopt Section 3 of the Snapshot.
- RESOLVED: Publish Snapshot.
white-space:pre-wrap and pre-wrap-auto
--------------------------------------
- Florian and fantasai agreed that the spec should say something
along the lines of the UA must provide a smart behavior and
should match platform with 'be smart' defined as 'provide a
good experience'. They will work on solidifying the wording.
- RESOLVED: In pre-wrap, disallow wrapping before the first space.
Behavior of scrollLeft in RTL or vertical-rl mode
-------------------------------------------------
- The right people weren't on the call for a resolution, but
webkit plans to change to be more consistent with the proposal.
The 'inline-{start,end}' values for 'float' and 'clear'
-------------------------------------------------------
- This issue needs a consistent decision between all 2d
positioning, not just for floats. It was added to the TPAC
agenda.
Default Alignment of Grid Tracks
--------------------------------
- There was a strong feeling from Rossen that there wasn't a need
to make Grid and Flexbox consistent in their 'auto' value for
alignment.
- The spec will be left as-is for now and fantasai will look for
more feedback, especially from authors.
Fragmentation Issues
--------------------
- RESOLVED: Issue #19 is out of scope.
- RESOLVED: Take Roc's suggested wording about keeping inline
blocks non-fragmented (Issue #21)
- RESOLVED: Each fragmentainer must contain at least some content
or fragment of content.
- Issue #24, adding 'force' to the page, column, and region
keywords, still needs to be discussed either on a call or at
TPAC.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2015Oct/0062.html
Present:
Rossen Atanassov
Tab Atkins (IRC only)
David Baron
Bert Bos
Bo Campbell
Tantek Çelik
Alex Critchfield
Greg Davis
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Dael Jackson
Brad Kemper
Peter Linss
Myles Maxfield
Edward O'Connor
Anton Prowse (IRC Only)
Florian Rivoal
Simon Sapin
Alan Stearns
Johannes Wilm
Greg Whitworth
Regrets:
Adenilson Cavalcanti
Dave Cramer
Simon Pieters
Lea Verou
scribe: dael
TPAC
----
glazou: Let's get started.
glazou: Before extra items, let me remind you we have to collect
items for TPAC discussion.
glazou: If you haven't registered for TPAC you should do it today
because the fee doubles tomorrow morning.
glazou: That said, I think there is at least one agenda extra item
from Bert about Houdini. Anything else?
glazou: So Bert you asked about the Houdini meeting?
Bert: I was asked if we still needed a room. I remember there was
a doodle, but I don't know the conclusion.
Rossen: Let's look. There were a couple of efforts started to get
more data. One was I asked people to sign up on the
Houdini wiki.
Rossen: There was not too much sign-up there. I guess the doodle
was created which got more people to post. Based on the
doodle we can take time off of plenary. Or Thursday or
Friday are good days.
* glazou leaves on friday and will not be available thursday
afternoon, would prefer thu morning
Rossen: Back to if we should meet, we've agreed to meet. It's a
question of do we do it Thursday, or Friday. Or play hooky
on plenary day.
Rossen: I didn't see anyone sign up from Apple though they brought
up the conversation.
hober: I'll bug dino.
Rossen: Do you know if he has a preference?
hober: I don't know.
Rossen: But someone from Apple will be there?
hober: Yes.
Rossen: Based on the doodle Wednesday works for most except dbaron.
Friday morning is good for everyone.
glazou: I plan to attend Houdini, but I'm leaving Friday and the
plenary day isn't good. I'd prefer Thursday morning.
Rossen: It's an option. There are 3 people conflicting with
Thursday. dbaron, Florian, and dauwhe. They're not
opposed, they're listed as 'if needed'. If we say it is
needed then let's shoot for that. Reserve the room on
Thursday and go from there.
Florian: So plenary didn't work out?
Rossen: For plenary day...I would be in favor of it if we need it,
but I would like to poke into different meetings that day.
astearns: I think having a specific topic for Houdini on plenary
would make sense.
Rossen: Or make it a Houdini awareness topic.
Rossen: Or is that what you meant?
astearns: Instead of a general 'this is Houdini' or 'let's discuss
topics', I think it makes sense to have it be specific
like CSSOM or Box Model so people can decide to go.
Rossen: Okay. Let's book a room for Thursday. If someone puts a
specific topic forward for Wednesday let's also book
something for during the day Wednesday.
Rossen: That way we'll narrow down the people interested in that
specific topic. So if, for ex. we do CSSOM people not
interested can join other meetings. We'll have the
standard with everyone Thursday. How does that sound?
Florian: Worth a shot.
Rossen: Okay, let's have that. I'll update the Houdini mailing
list and we'll go from there.
Bert: I'll take care of the Thursday. Someone else want to take
care of Wednesday?
Rossen: If we can get a room for the whole day on Thursday that
would be best. I'm not sure if we'll spill to Friday. If
we do we'll play by ear.
Rossen: Definitely having one room for Thursday is great.
Florian: And Wednesday can be done last minute. We don't have to
write it in advance.
glazou: We always spend 30 minutes writing topics on the wall.
Rossen: So we'll leave Wednesday to be spur of the moment. All of
Houdini will meet Thursday. Same goes for Friday, if
people are around and we need to discuss we will.
Snapshot
--------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015OctDec/0000.html
glazou: TabAtkins said it's been a month since the mostly final
wording and all requests for additional clarification have
been made. fantasai, is there a specific request to
publish or...?
Florian: We were waiting on Apple and Microsoft. They tentatively
agreed but wanted to check with a team.
gregwhitworth: We're good with it.
hober: I don't think we have additional feedback.
hober: I don't think we have consensus internally, but it
shouldn't hold anything up.
Florian: Meaning whoever is disagreeing will be made to agree?
hober: I didn't say it, but it sounds good :D
glazou: Let's suppose we have consensus on the doc.
fantasai: So here's what we've got...what we plan to do is if we
have a resolution to accept section 3, that's the main
thing holding up publication. That's part of the boiler
plate added to every spec. Once we have a resolution
we'll update bikeshed. We'd like to publish the snapshot
itself.
fantasai: We'll update the snapshot again this year because we
don't have the table of properties.
fantasai: We need resolution to adopt section 3 of the snapshot
and a separate resolution to publish the snapshot.
<fantasai> https://drafts.csswg.org/css-2015/#responsible
glazou: Opinions?
Florian: Yes, let's do this.
* TabAtkins hopes we can publish the 2015 snapshot in 2015
glazou: I agree. +1
<SimonSapin> +1
<fantasai> +1
glazou: Objections?
RESOLVED: Adopt Section 3 of the Snapshot.
RESOLVED: Publish Snapshot.
fantasai: Okay. Excellent.
<fantasai> ACTION: fantasai publish Snapshot 2015
<trackbot> Created ACTION-724
<fantasai> ACTION: TabAtkins update Bikeshed to spit out new
wording
<trackbot> Created ACTION-725
white-space:pre-wrap and pre-wrap-auto
--------------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Sep/0272.html
<glazou> and https://lists.w3.org/Archives/Public/www-style/2015Sep/0228.html
Florian: Two things. One isn't so much about behavior, but if it's
allowed. From NYC meeting we set this specific behavior
for white-space:pre-wrap and created pre-wrap-auto which
lets browsers do something they may prefer.
Florian: fantasai wrote the spec prose that said the browsers may
deviate in order to match platform conventions. But, for
example, Chrome does its own smart thing so I'd rather go
with language saying it should match, but not must. We
can't test that a browser matches platform conventions so
I don't see the point of maintaining. I think should and
please do something smart is better.
Florian: Especially given that Chrome doesn't match.
fantasai: I think we should say something about what the point of
deviating from the standard behavior should be.
Florian: I think one thing is there isn't a platform convention.
There's default text control, but all text based editors
behave differently. So, why would you do something
different? It's because you've decided for editing the
behavior you want is more user friendly, even if it
doesn't match.
fantasai: We should have a goal for allowing implementation to be
non-interoperable. If the goal is create a better widget
for text editing, let's say that. If the goal is match
platform conventions, say that. If the goal is do
something different for the sake of different, that's a
problem.
Florian: I was attempting to word along the lines of the UA must
provide a smart behavior, should match platform. And be
smart is defined as provide a good experience.
fantasai: I'm okay with that.
Florian: So match platform conventions and if you can do better go
ahead.
fantasai: Let's word smith this unless anyone else has something
to say.
Florian: I'll send a pull request and we can discuss.
koji: I wasn't at NY, but I think this issue has two prospectives.
One is if platform convention should be allowed. Engines are
not agreeing, but if we want two values, one for platform
and one that doesn't, that's okay. My concern is if pre-wrap
wraps before a space.
Florian: That's the other issue.
Florian: The resolution we had allows wrapping before and after
spaces. But koji and fantasai have concerns. koji wants
no wrapping before the first space and fantasai assumed
that. Should we re-resolve? It seemed reasonable, but you
guys disagree.
fantasai: I think that would cause a problem...it's common to use
single spaces to separate words and you'd have a lot of
single spaces at the beginning of the line. Multiple is
more reasonable.
<fantasai> to wrap
<tantek> agreed with fantasai
Florian: We could do a between. You don't wrap before a single
space, but if you have a single at the end of a line that
overflows you don't count it as an advance and you let
the single space overflow. Or that's too magic.
koji: That's more magic to me. There's no editors that do that.
Florian: I'm not sure about that.
Florian: There's so many editors doing different things I'm not
sure which does that. If you have a word space word and
if it doesn't fit you wrap the word and no matter what
the space doesn't wrap.
<tantek> plenty of editors do that. iOS "Notes" app for example,
and "Messages" as well.
<tantek> extra spaces at the end of the line just stay on the end
of the line, until you type a visible character, then
that character starts the new line, not the spaces
fantasai: There's two main goals. One is present code and in that
case you want every character and not wrapping in the
middle of a long line of spaces is awkward. The other
use case is I'm editing and I want to wrap stuff and
when I hit space I should hit that because it's plain
text. If those are the two use cases...code and plain
text...then doing code which is pre-wrap should display
every character and not do magic collapsing.
fantasai: The other should do whatever intelligent things it wants
to do to make plain text editing happier.
Florian: I'm sold.
<tantek> existing plain text editors do not wrap spaces at the end
of a line
<tantek> I'm disappointed by the lack of specific examples
<tantek> to back up these claims of "code" vs. "plain text" editors
koji: The point I made is when you're editing code you wrap before
space and break with it.
Florian: So if the only change is we don't allow a break before
first space, you're happy...is that correct?
koji: After every space...what about between spaces?
Florian: In pre-wrap you do wrap, but not before the first one.
koji: I don't like that.
Florian: Why?
koji: My experience is word processors don't expect spaces to wrap
to the next line.
<tantek> exactly!
Florian: We have pre-wrap-auto which does what you want from a
word processor. If you want a simple mode where I press a
space and the space appears, we don't have that.
koji: If you want code editing you want to break between words too.
That's a break-all.
fantasai: break-all is between every character. It's not about
spaces.
Florian: I disagree that in a code editor you want to break
mid-word. I don't want that.
fantasai: No one does that. Maybe in Japanese.
koji: They do between words.
fantasai: Not between letters.
koji: I think we should create a list of editors.
Florian: I tried to start with a list, but it left people more
confused.
glazou: We're starting to take too much time.
Florian: If we make the change I suggested, fantasai is okay with
it. You had a bug filed against Chrome that would be
fixed by how we're presenting. We're fixing that it
breaks before the first space. It's a first step and we
can look again.
koji: I don't like spaces to wrap to next lines.
Florian: We had an hour+ discussion about this in NY. I'm not sure
we should have it again now. I'm proposing that for now
we fix what we did in NY and if you want to revisit the
whole NY discussion we can do that at TPAC.
Rossen: I'm not hearing too much new information that wasn't in NY.
If this is a discussion just to re-discuss, perhaps we can
leave it for TPAC?
Florian: And we need drawings.
glazou: Let's conclude.
Florian: So do we have a resolution to fix it?
glazou: Not yet. Can you type the proposed resolution?
<Florian> proposed res: in pre-wrap, disallow wrapping before the
first space
glazou: Comments or objections?
Florian: Given that we might reopen the whole topic.
koji: I'd rather mark an issue.
<tantek> Agreed - leave it as resolved NY
<tantek> anyone that wants to change it - provide a written
proposal, and instead of plain assertions "editors do
this", or "code editors do that", or "plain text works
like this" - provide SPECIFIC examples of WHICH editors,
so we can verify your claims
Rossen: Florian you had a test case. Can you share that?
Florian: Let me find them. I'll paste in IRC.
<Florian> http://florian.rivoal.net/csswg/wrap/
glazou: koji to answer you, this is not a moment to discuss what
to do instead. There's a proposal, do you object to it?
koji: I want to mark an issue.
glazou: koji, you want to mark an issue. Do you object to the
proposal?
koji: I don't object.
glazou: Any other objections?
RESOLVED: in pre-wrap, disallow wrapping before the first space
Behavior of scrollLeft in RTL or vertical-rl mode
-------------------------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Sep/0303.html
glazou: This is from zcorpan. He can't be on the call.
<glazou> for the telecon which i am not able to attend today, re
"Behavior of scrollLeft in RTL or vertical-rl mode", IIRC
the spec is intended to match Gecko. i can look into it
more closely tomorrow
glazou: So Mozilla people, is there anything else to say?
* fantasai hasn't got a clue about this issue, fwiw
smfr: Webkit is buggy in this area. I agree with the proposal and
at some point webkit will change to be more consistent and
do that.
glazou: Maybe we need to wait for zcorpan to resolve.
glazou: zcorpan's comment was on the message link I posted.
dbaron: What was zcorpan's comment?
glazou: [reads]
dbaron: Okay. That's fine.
smfr: Edge is also inconsistent. Does Microsoft have plans to fix?
Rossen: Unlikely, but I'll look into it.
The 'inline-{start,end}' values for 'float' and 'clear'
-------------------------------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Oct/0062.html
Florian: Is johanneswilm on the call?
johanneswilm: Yes.
johanneswilm: I wasn't part of the conversation, but whatever the
outcome is it should apply to page floats. I would
say keep as-is, but if people want just start and
end I'm fine with that.
Florian: If we have 2d and it can do inline and block, keeping it
explicit is preferable so keep as-is in page floats.
koji: I agree, but have concerns. Can authors remember if this
property is 1d or 2d and understand that it's inline is
confusing. That properties can be changed between 1d and 2d
can create changes.
Florian: If you a float with block-start you're not moving inline;
it's clear.
koji: Block-start is clear.
koji: But how people distinguish why a float is start is confusing.
Florian: If you do float start nothing happens. Therefore you
should use inline-start
Florian: But I see your point.
* bradk thinks it would be more confusing if one said 'block-" and
the other didn't say 'inline-'
<tantek> anything with float is confusing
<SteveZ> I agree with Koji, we have, to date, only use "start" and
"end" for inline. Therefore, they need no prefix. We
should use other keywords for block direction
fantasai: We're looking into this for other properties. What I
think is we should get a list of what are all the
properties that need the keywords and look together. I
think I'm happy with inline-start and -end for now.
Possibly allow both. I don't know. I've been looking at
2d positioning a lot. One thing I concluded looking at
background positioning syntax is that being super
verbose is sometimes convenient and sometimes not. So
having start start is convenient sometimes.
fantasai: We might want to codify the ability to shorten the
syntax. But it's also useful when you only need one
keyword it's nice to put that one and not try and decide
which to set null.
Florian: And in floats you can't move arbitrarily in 2d so the
position things doesn't apply for now.
johanneswilm: Until we have 2d floats.
Florian: Which will probably happen.
fantasai: The best conclusion I have now is we should have start
and end for now and we should think on this further.
It's a complicated situation and looking at float in
isolation won't get us the answer. But I don't think
this is for the call.
johanneswilm: Agreed.
koji: I'm good with that.
SteveZ: So we should talk about that with TPAC?
fantasai: Yes. We should do all the logical things. I'll add to
the agenda.
glazou: Anything else on that topic?
Default Alignment of Grid Tracks
--------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Oct/0022.html
fantasai: In the alignment property, in the past we had the
ability to use content distribution keywords like
stretch in flexbox, but not grid. We added it in grid,
though. The alignment spec was written before that. It
said the initial value is 'auto'. For Flexbox 'auto' was
'stretch' and for grid it was 'start'. Now it's
inconsistent that they don't behave the same. So the
proposal is to make grid follow the flex setup. The
initial value for align-content would stretch the tracks.
Rossen: I do like to keep flex and grid consistent as much as
possible. I'm not convinced this issue needs to be
resolved in favor of keeping them consistent. Stretching
in flex is a lot more common and expected than it is in
grid.
Rossen: Having the 2d layout and behavior of grid compared to that
of flex, it doesn't naturally suggest that items or trunks
should be stretched.
Rossen: I'm in favor of keeping grid as start. The argument that
Javier is making that it's more work, I don't buy that.
You have to make both work and it comes from an initial
value, not adding more code.
fantasai: To clarify, the effect of making it stretch only effects
auto-sized tracks.
Rossen: I know what it effects.
fantasai: But you're not the only person on the call.
fantasai: It effects auto-sized tracks and only by making them
bigger if there's extra space. You'd have auto-sized
rows and if your container is taller than the rows the
extra space would get distributed.
fantasai: If your grid was auto height to begin you won't have
extra space.
Rossen: I said what I have to say. Even with that...fantasai was
restating how it works. My comment/feedback remains.
fantasai: Are there other people with thoughts? Or would like time
to look?
glazou: Apparently not.
fantasai: I'm not convinced yet, but I'll leave spec as-is until
there's other information or comments.
glazou: Okay. No resolution for that. We have 8 minutes on the
call.
Rossen: Isn't the resolution to not change anything? Just for the
people commenting on the thread so they have feedback?
fantasai: I think we should be looking for more feedback at this
point. Particularly from authors.
glazou: I agree.
Rossen: You have one that's speaking right now.
Florian: You're not an author.
glazou: Anything else? We'll close this one. We need more feedback.
I agree with Florian that you're not only a user/author.
Fragmentation Issues
--------------------
<fantasai> https://drafts.csswg.org/css-break/issues-lc-2015#issue-19
fantasai: Issue #19. How the OM model works for fragmented boxes.
I figured it's out of spec and the OM should talk about
that. I wanted confirmation that people feel that's a
reasonable conclusion.
glazou: I think so because otherwise it would block the spec.
glazou: Agree?
Florian: Yes.
astearns: Fine by me
RESOLVED: Issue #19 is out of scope.
<fantasai> https://drafts.csswg.org/css-break/issues-lc-2015#issue-21
fantasai: Next is a break in inline blocks. A line box cannot
fragment so what do we do with them? Roc proposed we
cannot fragment. That's fine by me. If someone wants
something else tell me and we can discuss.
SimonSapin: Sounds good to me.
Rossen: So keep inline block as non-fragmented? That makes sense.
fantasai: It's about if you have an inline block taller than the
page, what do you do?
Rossen: It's 2d fragmentation so yeah.
RESOLVED: Take Roc's suggested wording about keeping inline blocks
non-fragmented.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Sep/0153.html
fantasai: Next is about guaranteed progress. We resolved a
fragmentainer is 1px tall at least. But we didn't
resolve that you need 1px of content on that
fragmentainer.
Rossen: I thought we did.
fantasai: It's not in the spec.
Rossen: So we need to edit it that 1px on content is consumed.
Florian: Should it be 1px height or does it consume while
overflowing?
fantasai: We said it was 1px high.
Florian: But we should consume 1px of content.
fantasai: So you must place at least 1 thing on every fragmentainer.
SimonSapin: Should we talk about non-0 amount of something?
<tantek> nonzero++
Rossen: Since this is near error condition, can we leave the spec
to say content process must be made by ensuring
fragmentainers are at least 1px tall? The rest is implied.
How the content is consumed is decided by what content it
is.
fantasai: I think someone will say let's push this to the next
page because 1px is too small. We're missing from the
spec that progress is being made.
Rossen: Yes. Let's not be too specific.
fantasai: Yes, you must place a thing. Put whatever you can, but
there has to be 1 thing.
Rossen: Okay.
fantasai: So each fragmentainer must contain at least some content
or fragment of content.
Florian: I like non-0 amount of content.
fantasai: Okay.
RESOLVED: Each fragmentainer must contain at least some content or
fragment of content.
<fantasai> https://drafts.csswg.org/css-break/issues-lc-2015#issue-24
fantasai: Last issue, I'm just presenting. During last F2F hober
suggested page, column, and region keywords would be
clearer if prefixed with force. So do we want to rename
them. We're out of time, so we can't discuss. It's on
the agenda, though, and should be discussed at some point.
glazou: We have 1 or 2 calls before TPAC so we'll do it there if
we don't get a call.
glazou: I know some of you will be away the week before TPAC so
can't do a call. If you know you can't be on the call that
week, please let me know. I'm skeptical that we could make
quorum for that call.
* fantasai will be traveling, but can attend the call
* SimonSapin same
<dbaron> I'll still be around the Wednesday before TPAC.
Received on Thursday, 8 October 2015 11:33:41 UTC