- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 27 Sep 2012 16:04:54 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Add Brian Birtles (Mozilla) as editor of CSS Masking
- RESOLVED: Minimum size for running reftests is 600x600;
tests should be written to fit within that size.
Recommend that UAs use a rectangular viewport that is larger
than that if possible, to avoid missing errors due to symmetry
of square viewports.
- RESOLVED: FPWD CSS Counter Styles Level 3
- Discussed interpretation of IRIs in url() notation
- Discussed shrink-to-fit sizing of multi-column elements
- Discussed relationship of line grid module and line layout module
- Noted specs missing from priority lists
- Plan to take CSS3 Conditional to LC on October 10th, please review
and file any issues before then.
====== Full minutes below ======
Present:
César Acebal
Rossen Atanassov
Tab Atkins
Bert Bos
Tantek Çelik (via IRC)
Arron Eicholz
Elika Etemad
Daniel Glazman
Rebecca Hauck
Molly Holzschlag (via IRC)
Koji Ishii
John Jansen
Brad Kemper
Peter Linss
Edward O'Connor
Anton Prowse
Florian Rivoal
Simon Sapin
Dirc Schulze
Alan Stearns
Leif Arne Storset
Lea Verou
<RRSAgent> Logging to http://www.w3.org/2012/09/26-css-irc
Scribe: fantasai
Administrative
--------------
glazou: any extra items?
krit: Would like editor to Masking
krit: Would like to add Brian Birtles from Mozilla
krit: He's already worked on SVG masking spec
glazou: Any objections?
RESOLVED: Brian Birtles added as editor to CSS3 Masking
Counter Styles
--------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Sep/0464.html
glazou: Request from fantasai and Tab to publish FPWD of counter-styles
Florian: This is split out for CSS3 Lists?
fantasai: yes
Florian: It's removed all the stuff except CSS2.1 / CSS2.0 stuff?
fantasai: Yes, except ethiopic-numeric, because it can't be represented
by @counter-style. This is marked as an issue.
Florian: What about katakana / hiragana?
Florian: There was some question of how they behave, why not look at the
implementations that exist?
fantasai: No disagreement there
Florian: If there's no implementation, then remove them.
glazou: We have enough time to remove them in the future
glazou: Noticed one of the latest edits was edit to type attribute in
CSSOM (changed to system)
glazou: There was some discussion about that
glazou: Change seems good to me.
Bert: Can we change the shortname? Seems odd for CSS3 shortnames to be
inconsistent
Florian: Didn't we resolve to change it to the new pattern?
<TabAtkins> Yes, it's the new pattern that we'll change everything to.
Florian: Eventually we will migrate everything to the new scheme
glazou: We resolved on that last week
Bert: Think there's better things to do, but ok.
glazou: We need to. The current naming scheme has been inconsistent,
and it's confusing people.
Florian: I will object if they are not marked at-risk
fantasai: They're marked
glazou: It's in the status section
Florian: Ok, I'm good.
RESOLVED: FPWD CSS Counter Styles Level 3
* glazou reminder to all : read the conf call minutes as soon as they
are released and object - if you have to - as soon as possible
Viewport Size for Reftests
--------------------------
<glazou> http://lists.w3.org/Archives/Public/public-css-testsuite/2012Sep/0020.html
leif: Deferred so I could investigate what Opera needed.
leif: Essentially have no problem with 600x600
leif: Might need different size in the future, but probably would
prefer to mark that with metadata
fantasai: If we need a smaller size, then we should figure that out now,
not go back and mark tests that fit within the smaller size
and say the others can't be run on that size
leif: ... viewport tests probably need a special keywords ...
arronei: We should add a flag for tests that don't fit within 600x600
rossen: From past experience, when we had tests that rely on a square
container, sometimes this can hide some buggy implementations,
especially when dealing with different permutations of directions
/ writing modes / etc
rossen: when both containing width and height are the same, might hide
a buggy implementation there
<antonp> +1
rossen: if you're settled on 600x600, that's fine, but a square container
is prone to hiding some bugs
krit: Mozilla uses 1000x1000, and Webkit uses 800x600
rossen: 1000x1000 doesn't solve the issue I was talking about, but
800x600 would be perfect
<SimonSapin> +1, I had such bugs. (Non-square viewport is better)
rossen: also @media aspect ratios, setting square viewport can hide
some things that you want to find out sooner than later
fantasai: This isn't the size to use, it's the smallest size that you
can make the viewport and still capture all relevant data in
a screenshot
glazou: Enough info to make a decision?
fantasai: Yeah. We'll go with 600x600, and recommend that UAs use a
rectangular size that is larger than that if possible.
Florian: I'm mildly surprised no one needs a smaller size for mobile
testing
leif: Often the desktop viewport size is used
leif: If we wanted to go with the smallest mobile screen size, we'd be
at 240.
leif: That's a bit small.
RESOLVED: as fantasai summarized above
<florian> I am wondering if the size limit implies constrains on the
fonts that you can use when running the tests, as some fonts
may cause the text to overflow
Multi-column Shrink-to-fit
--------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Jul/0598.html
Sapin: The part of multicol about shrink-to-fit doesn't make sense.
We should just remove it.
fantasai: I agree with removing any implication that css3-multicol
defines multicol intrinsic sizing
Sapin: We can define it later in css3-sizing if necessary.
Bert: I didn't understand what the problem is
Sapin: css3-multicol sizing uses shrink-to-fit sizing when available
size is none, but CSS2.1 [...]
glazou: You said there is little interop in your email
Sapin: If we we make float multicol elements, we can see intrinsic size
without defining width
Sapin: Results are all over the place
fantasai: I raised an issue about multicol intrinsic sizing that Hĺkon
thought was in the spec not making sense anyway
glazou: Impact on the spec?
Sapin: [...]
anton: Make it explicitly undefined?
Sapin: Yes, we can add that it's undefined
Sapin: I don't know if, for example, Flexbox explicitly says the
preferred width is undefined
fantasai: No, we define it.
Florian: Easier for us and implementers if we make it explicitly undefined
rossen: Have another question here, can you elaborate what you meant by
"results are all over the place?"
11:30 -!- Rossen [Rossen@131.107.0.115] has joined #css
Sapin: For example, some browsers takes the preferred width as if the
element were not multi-column, and just use that
Sapin: Some browsers multiply the results by the column-count
Rossen: Were there any browsers doing what the spec is asking for?
Sapin: I don't know what the spec is supposed to be asking for
fantasai: I think we should make it's undefined, because the desired
behavior is unclear/unknown, and we don't have interop
Bert: It's already undefined in the spec, what did you want to change?
Sapin: I don't know how having an unknown available-width is useful
glazou: Seems to me some people need to do more investigation to resolve
this
rossen: We did a bit of work on this, I need to test a little on that
rossen: We read the spec at the time, and it kinda made sense
rossen: I would prefer if we can take this next week and then have a
few days to look around and see what exactly would that mean
glazou: We'll return next week
anton: Ca we get confirmation exactly what the proposal is
Sapin: Remove lines 3-10 inclusive
Florian: Seems we have to remove something, but unsure what the scope
of that its
URL notation and IRIs
---------------------
<glazou> http://www.w3.org/mid/4FBB2B56.9080805@mcc.id.au
<SimonSapin> URLs are ASCII only (and even more restrictive than that)
TabAtkins: We just have to make sure our definition of URLs includes IRIs
glazou: How many changes do we need?
TabAtkins: Just in css3-values
Florian: Some people complained that we shouldn't use the term URL when
we mean IRI
TabAtkins proposes ignoring that request.
TabAtkins: Everyone calls them URLs.
krit: CSS3 Images need to update to CSS3 Values and Units instead of
CSS2.1 then
glazou: Editing CR?
fantasai: This qualifies as a clarification, since this is what was meant
fantasai: I think I even had an issue marked on what the correct terminology
should be to include IRIs, and nobody ever commented on it
fantasai: So I just removed the issue.
<SimonSapin> RFC 3987 instead of RFC 3986
glazou: Also need to update the prose of the spec
Line Grid proposal
------------------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2012JulSep/0372.html
Florian: At the Kyoto F2F, fantasai made a line grid proposal
Florian: Everybody liked it, and since there was the Line Layout module,
people wanted to put Line Grid into Line Layout
Florian: But since then it seems Line layout is complicated and moves
slowly
Florian: Propose making it its own module, and moving it forward
Szilles: Line grid is equally complicated, because you don't know what
to align with the line grid
Florian: I agree there are ambiguities in what will happen until Line
Layout is finished
florian: But [...]
szilles: No, it's because of the way line-height is defined
szilles: You don't know where the baseline is within a line
fantasai: Isn't that only true when something is vertical-align: bottom
or top ?
szilles: don't recall, but not about differing baselines
Florian: Seems to me in generalized situation what you're saying is right,
but there are a lot of cases that would work
szilles: I guess I disagree, since if you don't figure this out from
the beginning you won't get it right
szilles: But I will commit to having a Line Module layout by Lyon
Florian: Couldn't we still have different modules that depend on each
other? Or is dependency too strong?
szilles: you need a definition of lines that works
anton: I think you'll end up relying on dependencies that aren't thought
through
glazou: Since Steve's committed to giving us a module by Lyon, I suggest
waiting until then
Florian: Ok, that's fine
More Administrative
-------------------
glazou: end of agenda, anything else to discuss?
fantasai: Do we have dates for F2F in February yet?
molly?
glazou: Proposed 4-6 of February in Tucson
Florian: pending confirmation
glazou: I have an exclusion in February, there's a W3C workshop about
EPUB in NYC 15-16 of February
glazou: So would like to avoid those dates if we ever change
szilles: don't think molly can do those dates anyway
fantasai: So just need Molly to confirm dates?
<molly> It is dependent upon availability and sponsors - but I will
leave those days out
glazou: Anything else?
Florian: Yes, about your priority lists, seems to me there were some
specs missing. Maybe re-issue an updated list?
glazou: People already commented that they were missing, so I hope
responses included them
fantasai: If they didn't include them, need to go back and ask
Florian: Public responses missed e.g. CSS Variables
glazou: Ok, I'll deal with that
glazou: Peter and I will go through responses before TPAC so we can
discuss, so really need responses soon so we can aggregate
data
* molly needs dates of next SVG meet too is it in feb?
@supports
---------
fantasai: For CSS3 Conditional, Tab and I plan to request LC on
October 10th telecon, that's in 2 weeks. Please review
and send issues before then.
Meeting closed.
Received on Thursday, 27 September 2012 23:05:25 UTC