[CSSWG] Minutes Telecon 2012-10-24


   - 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 ======

   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


   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
   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
   <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
   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)


   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
   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
   antonp: where the layout changes as reflection of other properties
   antonp: Think need to think about that different way of thinking about

   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

   glazou: Let's add this to list of topics for TPAC, but give it a time
   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
   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
   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
   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