- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 12 Sep 2012 17:06:53 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- John Daggett summarized the state of the font load event proposals.
He is incorporating feedback this week and plans to publish an
updated WD soon. http://dev.w3.org/csswg/css3-fonts/#font-load-events
- RESOLVED: Accept CSS2.1 edits in
https://lists.w3.org/Archives/Member/w3c-css-wg/2012JulSep/0293.html
- CSS2.1 edits up for review in
http://lists.w3.org/Archives/Public/www-style/2012Sep/0041.html
- RESOLVED: Boxes whose contents break above the bottom of the page
are drawn to the bottom of the page and consume height
to the bottom of the page.
- RESOLVED: Mark the non-2.1 Counter Styles as at-risk.
- Co-chairs have sent out a prioritization / implementation interest
survey to WG members and request its return, with the inclusion of
CSS Ruby, which was left out.
https://lists.w3.org/Archives/Member/w3c-css-wg/2012JulSep/0301.html
(In the interests of increased disclosure, the replies will be private,
and aggregated results will be made public.)
====== Full minutes ======
Present:
Rossen Atanassov
Tab Atkins (late)
David Baron
Bert Bos
John Daggett
Elika Etemad
Daniel Glazman
Rebecca Hauck
Koji Ishii
John Jansen
Peter Linss
Ted O'Connor
Anton Prowse
Alan Stearns
Leif Arne Storset
Lea Verou
Regrets: szilles (AB meeting), brad, smfr (Apple event), florian, rbetts
<RRSAgent> logging to http://www.w3.org/2012/09/12-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2012Sep/0222.html
Scribe: fantasai
Administrative
--------------
glazou: any additions to agenda?
glazou: First topic is Sunday of TPAC, but we don't have any news unless
Bert joins
<Zakim> +Bert
glazou: Any info on TTWF location in Paris?
rhauck: We're working on it,
rhauck: if anyone has suggestions, let us know
rhauck: we'll email the list when we know
rhauck: hoping by end of week
Bert: We reserved the room for Sunday, will be in the Hotel de la Cité
Concorde, in the conference center
glazou: Marie-Claire is planning a W3C meetup on Monday evening at the
city hall of Lyon
glazou: Will be general meetup aobut W3C and our specs and tools built
on our specs
glazou: Will collect items, if you want to speak, ping Marie-Claire
Counter Styles
--------------
http://lists.w3.org/Archives/Public/www-style/2012Aug/0916.html
glazou: maybe defer this until Florian can attend
Font Load Events
----------------
<glazou> http://dev.w3.org/csswg/css3-fonts/#font-load-events
jdaggett: started out as proposal from Florian (?)
jdaggett: topic brought up a number of times, need for events that
indicate when fonts have been loaded
jdaggett: reason for this is that there could be content on the page
need to be measured, can't happen until fonts are loaded
jdaggett: we've had several rounds of posts about font events from a
couple years ago
jdaggett: Tab recently proposed something
jdaggett: I didn't like it, so I posted another proposal, in the spec now
jdaggett: we need events for @font-face fonts b/c used lazily; not
loaded until they're used
jdaggett: Wanted to get from this call whether people happy with this
proposal, flush out any possible objections
jdaggett: Interface is still in flux; several people sent me private
emails discussing certain parts of interface, things they
find confusing, etc.
jdaggett: Basically 2 types of events
jdaggett: 1 gives you a way of identifying when all fonts are ready
jdaggett: page could include multiple fonts, e.g. a bold and an italic
jdaggett: It's hard for an author to track
jdaggett: Also events that fire per font
jdaggett: An app that wants to manage fonts very carefully would use
those
jdaggett: The existing WebLoader interface put together by Google is
supported
jdaggett: by several online type services is more like per font details
glazou: I read it and have no general comment; like it
Bert: I have no problem with the technology, just wondering what it
does to the schedule of the draft
Bert: Will it push back LC, or so easy will go ahead without loss of speed?
jdaggett: Think it can go ahead without loss of speed, b/c people are very
interested and sending lots of feedback
jdaggett: caveat is that the OM for CSS font face rule, leftover from CSS2
jdaggett: it uses CSSStyleDeclaration, which is odd
jdaggett: I'm starting to hear rumblings of people that this isn't a good
idea, switch to something else
jdaggett: others are ambivalent
jdaggett: Would influence this to a certain degree
glazou: Could you use a CSS Rule instead?
jdaggett: You need some place to define something like GetPropertyValue
so you can get value of descriptors
jdaggett: don't think need a setter for that...
glazou: To avoid putting null CSSFontFaceRule in document, use a CSSRule
jdaggett: What does that get you?
glazou: In the future if we change CSSFontFaceRule [..] you will get it
through CSSRule
glazou: The result would be CSSRule, but you say in prose it is a
CSSFontFaceRule
* fantasai is so confused
several people confused
* leaverou is confused too
glazou: You said that CSSFontFaceRule is subject to changes, b/c ppl
don't like how it is right now.
glazou: Suppose it becomes CSSFontFaceRule2 in the future
glazou: That will still query interface to CSSRule, and you can use that
as a reply to font-face attribute
jdaggett: Don't think on CSSRule there's any way to access info currently
contained in CSSStyleDeclaration
glazou: No, not saying that. Saying that giving reply as CSSRule lets
you have another interface in the future
dbaron: Not a question of which interface, question of what we want on
that interface
jdaggett: Existing implementations implement the old interface, so
have to consider that carefully.
jdaggett: I think I need to do more research on this.
jdaggett: Direct answer to Bert, but other OM issue could influence
the schedule.
jdaggett: If no one has other comments, then will continue to work
through details on the list
jdaggett: Since this is relatively major piece, once syntax worked out
on the list, would like to publish another WD
jdaggett: Sound reasonable?
yes
jdaggett: Ok, I'll work on this another week, then ask WG for publish
CSS2.1
------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2012JulSep/0293.html
anton: First is table box vs wrapper box and 'overflow'
anton: Observed that it's implemented on table box, but only some
values are supported
anton: others are handled as visible
<antonp> http://lists.w3.org/Archives/Public/www-style/2012Aug/0308.html
anton: I proposed some wording, hope everyone's happy with it.
<fantasai> works for me
<Zakim> +TabAtkins
Bert: Looks fine to me too
glazou: no objection, no other comments?
RESOLVED: Accepted
anton: Second issue is an idea to help the wording in various places
anton: going down a path we're going down a lot: defining terms we can reuse
anton: Want to define the term "block container element"
anton: "block container box" was introduced in CSS2.1
anton: A "block container element" is an element that generates a "block
container box"
anton: Don't have this wording in CSS2.1 yet, but would make fixing
various issues much easier
anton: I proposed this on the list, talked with fantasai, but no one
else involved in conversation.
<antonp> http://lists.w3.org/Archives/Public/www-style/2012Sep/0041.html
anton: Looking what other people think
anton: It's a long email, starts with motiviation
anton: follows with prposal
Rossen: Can I give you feedback a little bit later?
glazou: Ok, let's take a week to review this proposal and discuss it next week.
CSS3 Fragmentation
------------------
Scribe: TabAtkins
Consuming height at breaks
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Sep/0112.html
ScribeNick: TabAtkins
fantasai: I've been going back and forth on this.
fantasai: Rossen and I were talking last week about edits from the San
Diego f2f.
fantasai: one of the issues that came up was...
fantasai: If you have specified height on a box, that'll terminate *above*
the bottom of the page, and continue on the next page.
fantasai: You won't consume height between the cut and the next page,
and won't draw there either.
fantasai: That seems weird when you consider floats.
fantasai: Normally you have text wrapping around floats, and eventually
wrapping under it.
fantasai: But here, there's space you can't wrap text around it.
fantasai: Because the element isn't visibly taking up space there.
fantasai: So we were discussing whether you can flow content under a
broken float.
fantasai: And the answer is no.
fantasai: And so, if you're taking up space for the float, shouldn't
you draw it's background there?
fantasai: And if you're drawing it's background there, shouldn't that
space consume height?
fantasai: So we're considering reversing, and just making everything
draw to the bottom of the page and consume height. Thoughts?
antonp: I think it should draw to the bottom of the page. It's confusing
as a reader to see something appear to terminate, but then it's
there again at the next page.
antonp: I think I don't want it to consume height, though. Just calculate
the extra space and add it on afterwards.
rossen: In essence, what Anton is asking for is to have a fairly tight
coupling of content and containers, which is not present anywhere
else in layout.
rossen: You have content, which draws independently of its container
(to some degree).
rossen: The content is free to extend to whatever extent it needs.
rossen: The container may or may not take a dependency on that content.
rossen: If your height is auto, you stretch to the height; if it's
specified, you just stick with that regardless of content.
rossen: Let's take as an example a block container with something with
clearance on it.
rossen: If it's height auto, the clearance in the presence of a float
will extend the height of the container.
rossen: Back to fragmentation, we're asking the same question.
rossen: I have something inside which needs to be longer than it was
originally (extending to the next page).
rossen: The container may or may not take a dependency on that content,
and stretch to the content's height.
rossen: But if it's fixed, it's just fixed.
rossen: So if, in this specific case, we don't consume from the specified
height, now we're coupling content and containers.
rossen: And then my question is, why don't we do the same thing for
'clear' or similar mechanics?
rossen: That's why specified height is specified - if it's exhausted,
it's exhausted.
antonp: That makes sense to me. You're right to bring up that there's
two ways to look at it.
antonp: The question "why is height specified?"
antonp: It could be because of the relationship between the box and its
surroundings, or between the box and its contents.
antonp: If you're specifying a height because you're going to specify
properties on it that rely on that height, my answer won't be
good - backgrounds won't look nice if they depend on the total
size being fixed.
antonp: But equally, if you *don't* consume height, you might get the
same visual problem as before.
antonp: I can imagine a situation where content is fragmented onto the
next page.
antonp: There's a gap, but it's only partially filled now by the content.
antonp: You lose the visual indication that there can't be any more content.
TabAtkins: In that case, it's kinda like overflow:visible, which does
look horrible sometimes.
fantasai: Yes, you might have a background positioned relative to the
top of the box, so it looks bad if it continues.
fantasai: On the other hand, you may have two boxes that have a specified
height, because you want them to be the same specific size
(maybe they're side-by-side). If they break at different points,
they'll end at different points, when the layout of the rest
of the box depends on them being the same height.
fantasai: There's no answer that'll give us the right behavior in all cases.
rossen: You can also usually address this by specifying min-height instead.
In the non-fragmented case, they're the same height; if height
extends to higher than expected during fragmentation, it's auto
height and the container will stretch as necessary.
fantasai: One data point is that existing impls draw to the bottom of
the page and consume height.
fantasai: At least in Moz's codebase, it requires an extra level of
bookkeeping if we want to draw to the bottom of the page but
not consume height. You either do both or do neither.
fantasai: We're getting to the point of having more layout algorithms
with boxes side-by-side, which should draw to the bottom of
the page, and it makes sense for block flow to have the same
behavior, so you're consistent.
antonp: I wouldn't object to the status quo.
antonp: I think it should draw to the bottom. If it's easier, let's have
it consume height.
rossen: Again, I don't think anyone is suggesting the opposite.
rossen: The visual should be consistent with the layout.
TabAtkins: Agreed. I liked the ability to be smart about it, but you've
convinced me that we can't do good sufficiently often, so let's
just do the simple thing that's usually good enough.
plinss: My only concern is having a box accidentally overflow when it
wasn't intended to.
TabAtkins: Right, that's the time when it turns bad. But as Rossen points
out, there are ways around that (use min-height), and we can
always expose an explicit swtich afterwards if we want.
rossen: Reiterating, looking at different impls, that's the behavior you
have today with pagination. So the spec will be fairly consistent
with that.
rossen: So if we do introduce a smarter behavior, we may be looking at
compat problems.
plinss: I'll point out that the "impls already do this" is usually a
good argument, but most impls do such a bad job at pagination,
it's not really a very strong argument here.
fantasai: I'd agree with that.
fantasai: But there are cases where consuming the specified height will
cause overflow, and other cases where it will prevent overflow -
by not consuming the remaining space on the page, the container
may be longer than expected, and *it's* parent now overflows.
fantasai: Two boxes that are 100% tall in a fixed-height box, side by side.
fantasai: I break the page, one breaks at the end of the page, the other
breaks above it. If we don't consume height to the bottom of
the page for both, the second box will overflow its parent.
fantasai: So neither behavior works in all cases. It depends on the
layout, and depends on the content.
fantasai: Both answers are 50% good and 50% bad. So, the argument to be
consistent seems to win out.
Bert: I think it's fine, but could you summarize the conclusion again?
fantasai: The conclusion is that all boxes draw and consume height as
normal in the presence of breaks, to the bottom of the page
past the break.
Bert: Okay, I can agree with that.
TabAtkins: The point is that a break just does the equivalent of putting
a big spacer element in there.
antonp: If you glue the boxes back together, it's the total height.
<Bert> (The key is "consumes height", the border may indeed not even
reach the bottom of the page.)
glazou: Objections?
RESOLVED: Conclusion by fantasai about breaking, above, accepted.
Counter Styles
--------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Aug/0916.html
fantasai: I think florian's issue is that he'd like the counter styles
that weren't in 2.1 to be marked as at-risk.
TabAtkins: I'm fine with marking all the non-2.1 styles (the 2.0 styles,
and the replacement CJK styles) as at-risk.
RESOLVED: Mark the non-2.1 Counter Styles as at-risk.
CSSWG Prioritization Survey
---------------------------
glazou: I have one additional thing.
glazou: Koji, you're right that I missed CSS Ruby in the list of documents
in the prioritization email.
glazou: So please consider it included. I missed it by accident.
arronei: I have another comment on that list.
arronei: Did you send that list to some influentials, like Molly or Designers?
glazou: The Invited Experts in the WG got it.
glazou: I didn't ping anyone outside the WG.
TabAtkins: I think between our IEs we have enough "designer voice" to be
useful - Molly, Lea, etc.
sylvaing: I don't see anything in there that says "you have to be an
implementor to answer this", but if Anton thought he shouldn't
answer it...
glazou: Be sure that the entire WG's answer will be valued.
<leaverou> Did I hear my name or was it my idea?
<glazou> you heard well
<leaverou> glazou: Should I respond to that? I figured Bert will respond
for W3C
glazou: Lea, you have two faces in this group - on the one hand, you're
W3C staff, on the other hand, you're an influential member of
the design community. So we'd probably be interested in your
more personal opinions.
leaverou: Like what devs would like the most? Sure.
glazou: So, everyone, ping your AC reps so we can get the surveys back
in two weeks time.
Received on Thursday, 13 September 2012 00:09:31 UTC