- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 9 Apr 2015 06:37:01 -0400
- To: www-style@w3.org
TPAC
----
- The WG will request to meet on Monday and Tuesday during TPAC
Box Sizing
----------
- RESOLVED: New WD of CSS 3 UI, accepting changes to box-sizing
- RESOLVED: Then publish another WD
Motion Path
-----------
- RESOLVED: Motion Path FPWD granted
WebVTT feedback
---------------
- RESOLVED: Accept feedback coming from mailing-list as WG review
Media Queries
-------------
- A decision on the text change will wait another week for
Microsoft to continue reviewing.
Cursor Image Formats
--------------------
- Discussion will also wait until next week to give Microsoft
another week to review.
::marker
--------
- RESOLVED: Add the ::marker { font-variant: tabular-nums; } rule
to the default stylesheet
Intrinsic Sizes and Multicolumn Elements
----------------------------------------
- Discussion will continue on the mailing list and wait until next
week when someone from Chrome is on the telecon.
Baselines of Inline Blocks
--------------------------
- RESOLVED: Accept Myles' proposal to make baseline of overflow
non-visible inline blocks the higher of the actual
baseline (at initial scroll position) and the margin-
box bottom. Separately investigate whether to switch
from margin-box bottom to padding-box bottom for
sanity. (requries web-compat check)
====== FULL MINUTES BELOW =======
Present:
David Baron
Sanja Bonic
Bert Bos
Tantek Çelik
Dave Cramer
Elika Etemad
Daniel Glazman
Brad Kemper
Peter Linss
Myles Maxfield
Simon Pieters
Florian Rivoal
Simon Sapin
Alan Stearns
Greg Whitworth
Regrets:
Rossen Atanassov
Tab Atkins
Adenilson Cavalcanti
Simon Fraser
Dael Jackson
Michael Miller
Edward O'Connor
Mike Sherov
Shane Stephens
Steve Zilles
Scribe: glazou
TPAC
----
plinss: First topic, TPAC? pick dates.
plinss: Is the first part of week ok?
<dauwhe> Monday-Tuesday is good
tantek: I’ll be chairing a WG myself and will try to avoid overlap
<Bert> (I'll be there the whole week anyway, so no pref.)
glazou: Let’s stick to Monday-Wednesday.
Florian: Agreed.
tantek: Should we do Sunday too?
plinss: Not for now.
plinss: We’ll see.
plinss: Doing Sunday involves W3C planning and spaces.
Box Sizing
----------
plinss: next topic, box sizing
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Feb/0445.html
<tantek> latest message on:
https://lists.w3.org/Archives/Public/www-style/2015Mar/0405.html
florian: There's no feedback.
tantek: There is a thread with fantasai and TabAtkins.
Florian: Right, but nothing else.
tantek: I would like to move forward with this ASAP
tantek: There's still some issues where you agree with TabAtkins
but…
Florian: Also a couple wording points I agree with fantasai.
Florian: There's one difference between browsers I did not see
when I spec’d that.
tantek: The IE difference?
Florian: Yes.
Florian: IE returns the content width while others return the
width.
Florian: I think I agree with not-IE here.
gregwhitworth: We just got some edits on that this week.
Florian: OK, I will update the text then.
<tantek> this example:
<tantek> <div id="d" style="box-sizing:border-box;
position:absolute; padding: 10px;"></div>
<tantek> <script>console.log(getComputedStyle(document.
getElementById("d")).width);</script>
<tantek> Firefox/Chrome/Safari/Presto --> 20px
<tantek> IE --> 0px
<gregwhitworth> yeah, we don't want that since custom layouts will
need interop
Florian: My prose is probably correct although not elegant.
tantek: I can help with that.
Florian: 2.1 is ambiguous here.
Florian: fantasai suggested dealing with input and output.
Florian: Please help if you can.
tantek: OK.
* fantasai would also like to review the new wording
* fantasai really doesn't want to monkey-patch 2.1
* fantasai is pretty sure that'll create bugs in all of our specs
Florian: I need reviews from implementors.
tantek: We already gave 3 weeks.
tantek: We heard from tab and fantasai.
tantek: There's nothing from others, including Microsoft, excluded
what gregwhitworth just said.
tantek: gregwhitworth, did you review the rest of proposed text?
gregwhitworth: Unfortunately, no.
Florian: My proposal was posted end of February, ahem.
tantek: I’d like to suggest you go ahead, make the changes,
tantek: make the change explicit in the text,
tantek: and ship.
Florian: fantasai mentions not being happy about monkey-patching
2.1.
tantek: Unfortunately, we take the least worst approach at this
time.
* fantasai thinks you should check in the changes, and we can
clean it up afterward
* fantasai thinks we need to clean it up, but we should start from
something more solid than ML discussions.
tantek: fantasai just said she's OK with moving fwd the proposal
Florian: Let’s do it, then.
tantek: Sounds like a plan.
Bert: what exactly needs to change in 2.1?
Florian: The sizing section in 2.1 refers ambiguously to the value
of the width property and the width of the content box
because it was the same thing in 2.1.
Florian: So it's not clear how 2.1 works.
Florian: I made a clarification about that.
Bert: Yeah, ok, thanks.
Bert: Makes sense.
Florian: Same thing for height and min-/max- properties
tantek: Agreed that if can errata 2.1…
tantek: but probably it's better to get a wider review in CSS 3 UI.
tantek: I'm taking a wild guess TabAtkins would be ok with that.
tantek: Any other objections?
Florian: No objection obviously but I got rare feedback so does it
mean nobody reviewed it?
plinss: Wait.
plinss: Update and ask for WD?
plinss: I'm hearing no objection.
<fantasai> +1
tantek: Publish early, publish often.
plinss: Objections?
RESOLVED: New WD of CSS 3 UI, accepting changes to box-sizing
RESOLVED: Then publish another WD
tantek: the new publishing system was still crashing so we still
use the older one.
<tantek> Bert, http://dev.w3.org/csswg/css-ui-3/ is good to go for
WD publication now.
Motion Path
-----------
glazou: shane sent regrets
<astearns> +1 to fpwd
plinss: Any objections to FPWD?
RESOLVED: Motion Path FPWD granted
WebVTT feedback
---------------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JanMar/0239.html
plinss: Anyone have feedback?
astearns: We need to collect what’s in the list and send it ASAP.
plinss: That's fine by me.
plinss: Anyone needing more time?
Bert: Can you do it?
RESOLVED: Accept feedback coming from mailing-list as WG review
ACTION Bert to collect and send WebVTT feedback
<trackbot> Created ACTION-677
Media Queries
-------------
Florian: This is follow up of the should/must discussion.
Florian: Microsoft, we were waiting for you.
gregwhitworth: We have initial worries about pointer events and we
could not review.
Florian: We can definitely improve the prose there.
gregwhitworth: I don’t have a strong knowledge of that.
Florian: With the statement I’m willing to work on your pointers
concern, we should be ok with the general feeling.
plinss: Are you okay with that, gregwhitworth, or do you need another week?
gregwhitworth: I’d prefer having time to get internal review but I
don’t disagree necessarily with you Florian but...
plinss: OK let’s give them another week.
DEFERRED to next week: MQ4
Cursor Image Formats
--------------------
Florian: We were waiting for 2 different answers from Microsoft.
Florian: Are you OK with mandating image types, PNG and SVG, must
be supported and everything supported as an image must
also be as a cursor?
plinss: Rossen sent regrets and mentioned discussions and asked
for another week.
gregwhitworth: I got in touch with the standards people,
gregwhitworth: the ball is rolling now.
gregwhitworth: I asked yesterday and they said stuff is in MSDN
and they’re investigating legal issues.
gregwhitworth: Rossen was investigating technical issues and he
found nothing at this point.
tantek: That’s good.
tantek: One concrete proposal request: would it be possible to
contribute the cursor formats as a member contribution?
gregwhitworth: well ok
tantek: Microsoft has done it before.
<Florian> +1 to what Tantek said.
glazou: I said it too in www-style.
gregwhitworth: I will send the suggestion.
gregwhitworth: Let’s put that on agenda every week
all: :-)
tantek: count on us :-)
::marker
--------
fantasai: xidorn’s message is about font variants.
fantasai: We want to add that as a requirement on UAs.
<fantasai> ::marker { font-variant: tabular-nums; }
fantasai: Add it to default stylesheet for better results.
Florian: OK
Bert: You can still override it?
fantasai: Yes.
Bert: OK fine.
RESOLVED: add the ::marker rule above to the default stylesheet
Intrinsic Sizes and Multicolumn Elements
----------------------------------------
<fantasai> https://lists.w3.org/Archives/Public/www-style/2015Mar/0333.html
fantasai: Rossen reported an error in one of the bullets.
Scribe: sanja
fantasai: So basically we're looking at the intrinsic sizes of
multicolumn element.
fantasai: column-count, column-width, try to set as many columns
as you can, it will try to give you ... (talking about
cases) ... column-width, specify height on the element,
the columns will fill down and it will overflow on the
next side.
fantasai: ...so the minimum is the number of columns multiplied by
the minimum or maximum size of the content.
fantasai: Take the min content but max out at the width of the
column...[missed]
Scribe: fantasai
fantasai: col-width + col-count case
<dbaron> I strongly disagree with the height case.
fantasai: The last case is controversial.
fantasai: Don't think we can get resolution on it.
<dbaron> It would take me half an hour to load this stuff into my
head again; I don't know if this is the same as what the
proposal was the last time fantasai and I discussed it.
florian: I think Morten's position is probably right, since he's
usually right.
<Florian> (in general, and specifically about multicol)
fantasai: He didn't have anything much to say except for the last
case.
fantasai: I would like to get a resolution on the first three. I'm
happy to discuss on ML, but would like to know whose
reviews to wait for.
<zcorpan> i can ask morten for opinions about those
<astearns> agree with getting Morten's opinion
plinss: Anyone?
[silence]
Bert: I'm not sure I understand anything, but I suspect height
shouldn't have an influence here.
fantasai: The last case is what happens if you have col-width +
height
fantasai: Some implementors use intrinsic size as col-width
fantasai: resulting one column
fantasai: for the width of the multicol element.
fantasai: When you fill it with the content
fantasai: more columns are generated
fantasai: and the content overflows to the side.
fantasai: The goal of the proposal was to have the intrinsic width
be large enough to fit all of the content
fantasai: because that's what an intrinsic width usually does,
that is its goal.
fantasai: The problem with this is it requires layout.
fantasai: Except for multicol and orthogonal flows, we don't
require layout for finding intrinsic inline-size
fantasai: that would avoid overflow.
fantasai: So layout engines are unhappy that they would have to do
layout.
Bert: Don't think I can have an opinion in 5 minutes.
Bert: But looks pretty straightforward.
plinss: Maybe get a resolution on first 3?
fantasai: Chrome is the only one that would need to change, since
IE and Firefox agree on those.
plinss: No one from Chrome is on the call, come back next week.
[discussion of what to discuss]
<glazou> next topic, selectors 4
dbaron: That needs TabAtkins.
<dbaron> (if it needs teleconference time at all)
Baselines of Inline Blocks
--------------------------
<glazou> next topic, Baselines of inline blocks
<fantasai> Myles, from Apple
<Florian> welcome
<dauwhe> hello!
<tantek> Welcome Myles!
myles: The proposal is regarding inline block elements.
myles: Spec says if you have overflow: hidden;, you use the bottom
of the block.
myles: Would prefer the baseline of the last line or bottom of
block, whichever is higher.
myles: If you have without overflow: hidden, then use baseline of
text.
myles: If you add overflow: hidden, the baseline jumps up.
myles: Putting overflow: hidden shouldn't cause it to jump around
like this
myles: So would like to change baseline of the inline-block to be
whichever is higher, last baseline or bottom of block.
<astearns> I like this change. fewer surprises.
<dbaron> I'm fine with this change as long as it's based on the
initial scroll position, and that overflow
auto/hidden/scroll are consistent.
Florian: I'm fine with the proposal, but is it Web-compatible?
myles: Currently all browsers except WebKit implement the spec.
myles: WebKit has shipped this behavior for many releases?
dbaron: I'm fine with this. We get bugs about this at a decent
frequency, so I think the current behavior does bug people.
dbaron: I'm fine as long as we define it as initial scroll
position.
dbaron: And also if all of overflow: hidden / scroll are affected.
<tantek> sounds like an improvement to me too. assuming web-compat.
* fantasai agrees
fantasai: By "bottom of box" do you mean the content-box,
border-box, padding-box, margin-box?
Florian: The content-box?
fantasai: The scrollable area is the padding-box
myles: The spec right now says bottom margin edge
myles: That part I'm not proposing changing.
fantasai: That's kind of weird then, because you might have a
baseline that you can't see that it's aligning to.
dbaron: I think the margin edge is used to make it behave like a
replaced element, since those baseline-align to their
bottom margin edge as well.
myles: Boris and TabAtkins have said this is a reasonable thing to
do.
Florian: Since aligning to baseline, maybe should be based on
whether baseline is visible.
fantasai: Wouldn't that cause a jump? If I increase the font size
by 3px and [...]
Florian: No, I meant take higher of baseline or padding-box.
fantasai: Okay. I think that definitely makes more sense, if the
idea is to align to the content.
fantasai: We should take Myles's proposal, and then maybe try to
change margin-box to padding-box later depending on Web
compat.
plinss: Do we have a resolution?
[...]
RESOLVED: Accept Myles' proposal to make baseline of overflow non-
visible inline blocks the higher of the actual baseline (
at initial scroll position) and the margin-box bottom.
Separately investigate whether to switch from margin-box
bottom to padding-box bottom for sanity. (requries web-
compat check)
ACTION: TabAtkins and fantasai to update Box Alignment spec per
resolution, propose wording for CSS2.1 errata
<trackbot> Created ACTION-678
Received on Thursday, 9 April 2015 10:37:28 UTC