- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 24 Oct 2012 16:21:15 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Allow full flexibility in ordering for box-shadow.
Same requirements on what's required in the declaration (at
least 2 lengths). Edit css3-background accordingly.
- Discussed disallowing viewport-relative units in @page rules that
size the ICB, and also whether such units are resolved at computed
value time (relative to ICB) or used value time (relative to the
page). Plan to ask for feedback from CSS-to-print/PDF implementers.
- Discussed proposed edits to @supports to make invalid parenthesized
expressions also evaluate to false, rather than invalidating the rule.
- Discussed Tab's proposed draft for display-inside/display-outside/etc.
Will return to the topic at TPAC. Generally people feel this makes
sense. Some concern about being incompatible with Bert's mental model
of how CSS works, and whether authors actually need the property split.
- RESOLVED: BOM takes precedence over HTTP. Errata CSS2.1, edit
css3-syntax to fix this.
- Discussed rules for fragmenting inline blocks.
====== Full minutes below ======
Present:
Tab Atkins
David Baron
Bert Bos
Arron Eicholz
Elika Etemad
Simon Fraser
Daniel Glazman
Koji Ishii
John Jansen
Chris Lilley
Peter Linss
Edward O'Connor
Anton Prowse
Florian Rivoal
Simon Sapin
Dirk Schulze
Alan Stearns
Leif Arne Storset
Lea Verou
<RRSAgent> logging to http://www.w3.org/2012/10/24-css-irc
<antonp> Does anyone know any other numbers for Zakim? For me neither
the London one nor Paris ones go to Zakim. (The London one
goes to a company, and the Paris one goes to a private individual!)
<hober> antonp: iirc only the us number works; otherwise, there's sip
Agenda: http://lists.w3.org/Archives/Public/www-style/2012Oct/0680.html
Scribe: fantasai
Administrative
--------------
glazou: Any other items?
krit: [...]
krit: move discussion of masking to tpac
krit: ask for fpwd of masking at tpac
box-shadow syntax (css-background)
----------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Oct/0313.html
glazou: deferred from last week
leaverou: Where not ambiguous order shouldn't matter, since this is
how most of CSS works
leaverou: I've been confused by this many times
TabAtkins: I support this
* fantasai too
glazou: I think it does make sense
florian: In principle I agree, but wondering if it's too late to change.
florian: If it's rare enough that this will flip some invalid declarations
to valid an break sites, then ok
<ChrisL> if the order is 'either way' then it won't break, surely
florian: This is always something we have to think of when we turn on
things that didn't used to work
dbaron: I'm not too worried about this.
smfr: I think it's fine to change behavior in this case
glazou: Definition we have now is in CSS3 BG CR
glazou: So, if we accept such a change, when do we do it?
glazou: And where?
TabAtkins: I'm ambivalent about where we put the grammar change. Can do
it now
fantasai: I think if we do this, we should errata the CR so it remains
an accurate description of the features that are in it
ChrisL: you can't errata a CR, can only errata a REC. Could go through
last call or [...]
dbaron: I'm definitely supportive about the change in ordering, more
tentative wrt change to allow 1 or zero lengths
dbaron: We'd want to keep text shadow and box shadow aligned
dbaron: It'd be odd to write text-shadow: red; and have nothing show up,
but still show up
glazou: Can do the same with border: red;
TabAtkins: Would want at least one length
fantasai: first length is horizontal, not that useful. Discussion on
list said it's common to want only one offset, but want it
vertical
smfr: Would make sense for it to be just the blur radius
fantasai: I think we should defer that change to L4, to decide what the
single length should mean
TabAtkins: I agree w fantasai
TabAtkins: I think we should accept Lea's proposal to allow looser ordering
TabAtkins: Errata L3 for that
TabAtkins: Defer anything about omitting lengths for further discussion
and possible inclusion in L4
glazou: Ok, let's edit css3-CR and call it a clarification
JohnJansen: I will point out that nobody does this right now
JohnJansen: It's strictly a superset, so I think it's ok, but we need
to add testcases for it
Florian: I am not interested in a lot of process for that, since it is
a simple change, and it seems to me we are bending the rules,
but if the rule keepers are fine, then fine
ChrisL: Another LC wouldn't slow us down, b/c things we're held back
by are testcases and implementation reports
TabAtkins: Unless someone pulls out a full complete test report next week :)
glazou: Hearing consensus here, declaring resolution
RESOLVED: Allow flexibility in ordering for box-shadow
Same requirements on what's required in the declaration (at
least 2 lengths)
<JohnJansen> Actually, if Test The Web Forward goes as planned, we will
be close to having a suite for BnB next week. I'm working
on pulling the incoming tests together now.
Viewport Length Units (css3-values)
-----------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Oct/0398.html
TabAtkins: There's an issue on viewport length units in @page
TabAtkins: Since it references the viewport size, but it's defined to
set the width of the first page
TabAtkins: Should just disallow viewport-relative units in @page sizing
properties
<fantasai> Those would be margin/border/padding/width/height/size
SimonSapin: Note that Paged Media defines how the initial containing block
transforms across varying page widths. This also affects
these these units.
TabAtkins: Make sure to clarify that viewport-relative units are relative
to ICB, not current page size
TabAtkins: Need to be a bit more careful here
TabAtkins: If people want things relative to the page they're on,
viewport-relative units would have to become a used-value
time thing.
TabAtkins: Won't be super-useful for documents of varying page sizes
TabAtkins: But if that's ok with WG, relatively easy thing to write up.
fantasai: Think we should ask Simon and Antenna House about their
viewpoints, since they're the ones really dealing with this
kind of things. Browser don't really do varying-size
pagination or have strong use cases for paging.
antonp: Wanted confirmation that ICB is only first page
TabAtkins: Yes, it is.
antonp: So if you've got abspos element on page 10, it ends up on the
first page
TabAtkins: Gets positioned relative to the first page, though might
not wind up on that page depending on where it's positioned
Rossen: Also keep in mind that if you find an abspos on page 10 and
auto-positioned, will most likely stay on page 10
Rossen: But top: 0; will pull back to page 1.
TabAtkins: Ok, me or Simon would write up an email to Prince and
Antenna house explaining two options, and ask them what
they think
Conditional Rules
-----------------
TabAtkins: I asked for more time to review fantasai's suggestion, and
after talking with her last week agree with her position
TabAtkins: Not sure how to write it out, but just have to figure out
how to express elegantly
TabAtkins: Idea was that parenthesized groups have same error-handling
as an anonymous function; i.e. if you don't recognize the
grammar, treat it as false
TabAtkins: dbaron brought up problem that this might hide syntax errors
TabAtkins: But I don't think that's a huge issue, and that's kindof
the point too, for future syntax we add it's good
dbaron: I also think it's not a huge issue. @supports is just not very
typo-resilient
Leif: Haven't looked into this, but sounds fine from first look.
TabAtkins: We can make the reasonable edits this week or reasonably
soon, and that was last remaining issue.
Florian: I'd like to make this change fast, b/c have implementations
rolling out
TabAtkins: Absolutely.
fantasai: Suggest we make the edits, and just have a 3-minute conversation
about publishing LC at TPAC (next week)
Transforms
----------
glazou: Anything remaining for item 4?
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Oct/0513.html
krit: raised an issue with transforms that we have ?
krit: How to decompose 3D matrices
krit: how to decompose 2D matrices
krit: [breaking up]
krit: [something about computed value]
<glazou> krit: _extremely_ hard to understand what you say
krit: ... interpolation algorithm ...
glazou: We cannot hear you, suggest to defer to TPAC
<krit> ok, agree
Display Spec
------------
TabAtkins: I've been complaining about the way the dsiplay property
work since I joined the WG
<dbaron> http://lists.w3.org/Archives/Public/www-style/2012Oct/0552.html
TabAtkins: Conflates internal/external display modes
TabAtkins: And display none toggling
TabAtkins: Went ahead to draw up first draft of new display spec
TabAtkins: Four properties: display-inside/display-outside
TabAtkins: Two other properties, bad names
TabAtkins: 'display-box' for none behavior
TabAtkins: Added value for displaying the contents in place of the box
itself, i.e. as if the element wasn't there but its contents
were
TabAtkins: And another property for marker-box generation
TabAtkins: There's only one extra functionality, and some extra complexity
from splitting things up
TabAtkins: Hope it will make things easier to talk about
TabAtkins: [gives example]
TabAtkins: yay/nay? Take on as official work item?
florian: I agree with split into at least 3, a bit more discussion if
we need list-item behavior as a fourth item
florian: Other than that, think it's a good idea
Bert: This is something that we tried years ago, and I wrote it up,
but it failed to become intuitive
Bert: It's much easier to talk about an inline or a block in a stylesheet
than to talk about inside and outside independently
Bert: For cases where you say, sometimes you have to talk about things
that are a block inside, we can solve with terminology in the spec
Bert: Think need to talk to authors about their perceptions
Bert: In my experience, it doesn't really work
Bert: It was easier to not talk about it
TabAtkins: Cited your work as prior art
TabAtkins: For me, I just found the names confusing.
TabAtkins: display-model/display-role didn't make sense
TabAtkins: But I think the names might be part of the intuition problem
Bert: It was originally -inside/-outside, we changed it later
dbaron: I always liked -inside/-outside better. But not sure we ever
published with them
dbaron: we definitely discussed them
<ChrisL> Inside and outside seem very clear to me
TabAtkins: Also think I came up with a slightly more intuitive combination
of values
TabAtkins: With fantasai's help, realized I only needed three
display-inside values: block | table | auto
TabAtkins: Ended up being a really simple way to do it
TabAtkins: Can still use shorthand
TabAtkins: Think it works pretty reasonably
antonp: I really like the approach
antonp: Thought about it independently, and came up with a model similar
to Tab's
antonp: I think it is a useful way forward
antonp: My concern, from discussing with Bert, is that he has a very
mental different model
antonp: He felt that grid wasn't a display model, liked the multi-column
model
antonp: where the layout changes as reflection of other properties
antonp: Think need to think about that different way of thinking about
things
glazou: Your draft contains all the shorthand values and all the extensions
glazou: I think authors are mostly going to use shorthands
glazou: Seems the split is mostly theoretical
glazou: Not convinced we actually need the separate properties
TabAtkins: It's not just theoretical, for instance, we can't have a
display: table-cell that has a different internal model
than display: block
glazou: It's just a matter of new keywords for display
TabAtkins: New outside displays won't be possible to combine with existing
internal displays unless we create combinatorial keywords
TabAtkins: Yes, it's mostly about clearing up theoretical underpinnings
TabAtkins: But also gives better extension story
TabAtkins: Also, pulling out display: none into separate property is useful
antonp: I would really like to understand Bert's model first before
adopting this.
antonp: Otherwise, I'm happy to fly down this route.
Florian: Seems good thing to discuss at TPAC
<dbaron> I think this is a good face-to-face topic.
Florian: At Opera, this matches well with how our code is structured
glazou: What about other browsers?
arronei: I think IE has some of this separation internally, but not
quite to the extent we're talking about here
dbaron: We don't really have a separation in terms of display concepts,
but there are things that share the same code, e.g. blocks and
inline-block both block-inside. But don't quite track the
separation
glazou: Let's add this to list of topics for TPAC, but give it a time
limit
Florian: I think discussion should start with Bert explaining how he
thinks about it, b/c other than that I think everyone seems
to align with this.
BOM precedence
--------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Oct/0516.html
TabAtkins: Nobody disagrees, so I will go make that change.
glazou: You saying nobody disagrees is not enough for me, Tab.
<florian> I agree
glazou: What do Mozilla, others think about this?
dbaron: Henri's proposing this, and I'm in no position to disagree
with him
<SimonSapin> BOM precedence sounds good to me, though I don’t have
much experience with web compat
Leif: It would be nice to have some good tests for this.
TabAtkins: Hoping Anne can help out with that.
fantasai: if we're currently defining things a different way now,
then we need to errata CSS 2.1
fantasai: you can't fix this just by editing your syntax draft
Tab: OK, I'll investigate CSS 2.1 errata
glazou: Seems we all agree on this, let's move on
RESOLVED: BOM takes precedence over HTTP. Errata CSS2.1, edit
css3-syntax to fix this.
ChrisL: This affects UTF-16, and, if present, UTF-8
ChrisL: This is more in line with XML charset handling in
draft-lilley-xml-mediatypes
ChrisL: Also gives same behavior from filesystem vs web
ChrisL: Also some parsers don't have access to HTTP headers
<florian> also, if the BOM and http headers are in conflict, BOM
is more likely to reflect author's intentions, as ability
to modify the file is more common than ability to modify
http headers.
Koji: ... i18nwg?
TabAtkins: I didn't hear from i18nwg on this
[multiple people talking at once]
TabAtkins: Even if i18nwg hasn't, I trust work that Henri and Anne
have been doing, they've been extremely thorough
glazou: Anything else on this topic?
Breaking inline-blocks
----------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Oct/0563.html
glazou: Seems to need clarification
koji: Nested line boxes. Spec is not clear where it actually should
page-break
fantasai: It's complicated, because contents of a line box can be aligned
to each other.
<SimonSapin> keep this undefined?
fantasai: I would leave it undefined, b/c I don't have a good answer
Rossen: Consideration we had wrt fragment breaks, predictable approach
is you start laying out your line box in current fragment. If
you happen to overflow the fragment, and this is not the first
line, then you push to the next one to make sure that this is
the very first line
Rossen: At that point your inline content should simply break as any
other regular container would break, ensure you'd give the
line as much space as you can
Rossen: This is the only kind of predictable behavior that we thought
of, not sure that it's optimal
fantasai: The issue is happening when you're already at the top of the
page
Rossen: It's the same as for a very large font
fantasai: No, it's different. With a big glyph, the size of the glyph
does not change it when you slice it across pages.
fantasai: with an inline block, you have the option to slice it; or
you can fragment it
fantasai: if you fragment it, the height of the inline-block changes
due to the fragmentation
fantasai: this can then affect the position of other items on the line,
causing them to fragment differently, etc.
koji: Second behavior seems clearly better
fantasai: Yes, but it's complicated because of interdependencies between
alignment and size of box and point of fragmentation
* Bert wonders why you can't use a float if you want the box to be able
to break?
<Bert> Train strike on Thursday/Friday
<dbaron> www.airfrance.us does have a "Strike action on 26 October" warning on it
<dbaron> https://www.airfrance.us/US/en/local/information/news/news-air-traffic-air-france.htm
<Bert> One trade union announced strike on Friday for Air France, indeed.
There may be delays but Air France expects to transport everybody.
Meeting closed.
Received on Wednesday, 24 October 2012 23:21:46 UTC