[CSSWG] Minutes and Resolutions Oslo F2F 2010 Tuesday: GCPM, MQ, Flexbox, Multicol, box-shadow, Publications, Future F2Fs

Please start a new thread for replies, unless you are correcting the minutes.

CSS3 Generated Content for Paged Media

   Håkon would like to prepare the module for CR.
   Several people feel many of the features would be better placed in
     more appropriate modules, e.g. hyphenation to CSS3 Text.
   Some features may be underdefined.
   But nobody objected to any of the features fundamentally.

   Wrt hyphenation:
   - discussed hyphenate-resource property and use of local dictionaries
     instead of specified ones
   - discussed hyphenate-character property; it seems it should be able
     to accept a second character for languages where a second hyphenation
     character is used after the line break
   - discussed whether control is needed to prevent hyphenation on the last
     line of a page: plan to recommend the UA to prevent such hyphenation,
     add a control only if market determines one is needed
   - discussed possible use cases for specifying the hyphenation language,
     but none seemed needed -- the hyphenation language pretty much always
     matches the content language
   - proposed to replace 'hyphenate-resource' property with an at-rule that
     maps language tags to hyphenation resources, since hyphenation resources
     need to be specified per language, but not per element. E.g.
       @hyphenate-resource {
          en-US: url(en-US.hy);
          en:    url(en-GB.hy);
          fr:    url(fr.hy);
     * note from fantasai: this would allow more intelligent lang-code ->
       dictionary mapping than using :lang() selectors and a property

   Reviewed several other features including
   - cmyk() colors, which were proposed to rename device-cmyk()
   - bookmarks, which should have more examples added to explain their usage
   - super-decimal counter style, which has been moved to CSS3 Lists
   - line-box-contain, which needs more investigation

Hit Testing

   - Plan to add pointer-events to UI module edited by Tantek
   - Correct default behavior uncertain, needs testcases and investigation

   RESOLUTION: try and move AC review of charter forward, to get UI module
               in it and publish a LC asap.

Styling Attributes

   - RESOLUTION: publish style attr as CR.

Media Queries

   - Anne suggested including the media type definitions in MQ; WG
     considers this an editorial issue.

   - Reviewed status of test suite. Mostly waiting for another implementation
     to fix all its parsing errors; Mozilla passes all tests.

   - Anne suggested removing 'color-index'; WG disagrees.

Snapshot 2010

   - RESOLVED: 2010 Snapshot is 2007 Snapshot + Media Queries

Selector Serialization

   - Need a Selectors 3.1 spec to define serialization and OM
     (not required for UAs without an OM)


   - Discussed flex units and alternatives

   - RESOLVED: Out-of-flow elements are treated as placeholders
     during flexbox construction, similar to tables. ISSUE-138

   - RESOLVED: 'max-width/height' on a flexbox child limits the size
     of the element; if this results in a shorter box than any other
     in its row, it is aligned as if box-align: before. ISSUE-140

   - RESOLVED: Baseline of a flexbox is the baseline of its first
     child. Note: this may be revisited based on use cases. ISSUE-141

   - RESOLVED: box-ordinal-group also reorders stacking order; i.e.
     it reorders the box tree. ISSUE-142

   - RESOLVED: Preferred width of flexbox children is 'max-content'
     not 'fit-content'. ISSUE-143

   - Discussed distribution of negative space. Agreed that applying
     flex calculation with negative space is not ideal; alternatives
     to be investigated, including
       - ignoring flex when available space is negative
       - adopting TeX's glue algorithms
     ISSUE-144 http://www.w3.org/Style/CSS/Tracker/issues/144

   - RESOLVED: Contiguous non-replaced inline elements are wrapped
     into a single anonymous block. Atomic inline-level elements are
     individually wrapped into flexboxen. ISSUE-145

Multi-Column Layout

   - RESOLVED: Use border-collapse border-style behavior for column rules.

   - RESOLVED: Column rules are not clipped by the multicol element
     horizontally; but are drawn to the height of the multicol element

   - RESOLVED: Column rules are drawn "immediately below the border
               (above the background) of the multi-column element".

   - RESOLVED: Column-spanning elements have an effective column-span
     of 1 when occurring in an overflow column. ISSUE-129

       fantasai's post-meeting note: If a colspanning element has
       multiple lines, and some of them fit inside the multicol element
       but others don't, then the before-break and after-break halves
       of the element will be laid out at different widths?


   - Specification of box-shadow's blur radius has been fixed.

   - RESOLVED: Not altering stacking order of inset box-shadow to paint
     over content. May add keyword to do this in the future.

   - RESOLVED: Publish css3-background as CR.

F2F Scheduling

   Tentatively scheduled: March 7-9 (MTW) 2010 in Mountain View
                          June 1-3 (WTF) 2010 in Tokyo

====== Full minutes below ======

   César Acebal
   David Baron
   Bert Bos
   Tantek Çelik
   John Daggett
   Arron Eicholz
   Elika Etemad
   Daniel Glazman
   John Jansen
   Håkon Wium Lie
   Chris Lilley
   Alex Mogilevsky
   David Singer
   Steve Zilles

Partial (late afternoon via phone + IRC):
   Simon Fraser
   Sylvain Galineau
   Brad Kemper

<RRSAgent> logging to http://www.w3.org/2010/08/24-CSS-irc
Scribe: Bert

Tantek: Add UI to end of extra topics list?
Glazou: OK
<anne5> dsinger, http://dev.w3.org/csswg/cssom/ is the draft
<anne5> dsinger, last updated a couple of days ago; CSS Value API is the
         thing that I want to work out next
howcome introduces Leif, from Opera
Leif introduces himself. Worked on microformats, among other things.
Interested in hit testing.


   howcome: GCPM is [not] the garbage collection module. :-)
   howcome: We have two impls of most of the features.
   howcome: Prince and AntennaHouse.
   howcome: Last time we cut out the most experimental stuff.
   howcome: What's left is ready for CR this year.
   howcome: (First LC, of course.)
   John: Hyphenation is more useful than just print, should move to
         another module.
   <glazou> +1
   howcome: Several things are not just for print.
   howcome: I *do* like hyphenation to move fast.
   howcome: Not sure Text module will move faster.
   Glazou: But the title of the module is "Paged"

   howcome: A question about hyphen was how to do hyphenation dictionaries.
   howcome: Could be a separate module,
   Dave: As a naive user, I'd look for hyphenationin Text module
   howcome: And how about a separate module?
   Dave: That works, too.
   John: Related to justification.
   Tantek: What languages do the impls. hyphenate?
   howcome: Whatever they have dictionaries for. Prince uses TeX hyphenation
           algo and dicts,
   howcome: The 'hyphenate-resource' points to the dict.
   John: Format of those files defined?
   howcome: No, like 'icon', it is not defined what the reosurce format is.
   howcome: TeX is well-defined.
   Fantasai: Fonts have a way to specify format.
   John: It's not more than a hint, still need to ask server.
   howcome: Should it be the same as in fonts, then?
   John: One reason fonts is the way it is is that there was no font mime type.
   howcome: OpenOffice uses a different format, derived from TeX but not the same.
   howcome: So there is indeed a problem.
   howcome: But the impls. expect to ship with their own resources.
   John: Sometimes want to use system resource instead of the url of the
   fantasai: Use an 'auto' value to allow local resources.
   Dave: So you can get control by putting a 'local' value somewhere in the list.
   Glazou: The property is currently meant for exteranl (additional)
           resources only.
   fantasai: Mention somewhere that UA doesn't need to implement
             hyphenate-resource to be conformant.
   John: Is that handled as a syntax error?
   fantasai: Yes, exact as an unsupported property elsewhere
   Steve: How does it show up? Do you need to parse the property?
   fantasai: no
   glazou: From a pov of testing, failing the test is still succes.
   glazou: DOM doesn't matter for that.

   howcome: A more experimental, but very useful feature is 'hyphens: all'
   howcome: It puts a marker in the text at *all* possible hyphenation points.
   John: Limit to certain number of lines?
   howcome: See 'hyphenate-lines'
   [Discussion about the keyword 'no-limit']
   John: Can you hyphenate arabic?
   fantasai: Yes, I think so.
   howcome: Justification can be used with or without hyphenation.
   Fantasai: Typical impl. is to hyphanate first, then justify the resulting
   glazou: Hyphenate character: in some languages, you use a symbol both
           before and after the break. Is it always the same character?
   glazou: That has to be checked.
   howcome: Do we need to go as far as support a pair of characters?
   Steve: Ask the i18n WG...
   glazou: If you have hyphenation, you need to do this as well.
   [Dave gives example of old italian.]
   glazou: May need a separate property.
   howcome: Chris drew hanging hyphen. How do you do that?
   fantasai: That is in Text module. hanging-punctuation
   * glazou there's another _current_ european language using char before
            AND after the hyphenation break
   JohnJ: Could you find the proper character in the dict?
   fantasai: Don't know.
   howcome:Does anybody volunteer to do the research?
   glazou: We originally thought for list module to only have something
           simple. We were very wrong. Still not have all cases.
   howcome: I'd say reasonable approach is to provide what TeX provides.
   glazou: We have an I18N group, let's ask them.
   glazou: When they don't repsond, we can go ahead ourselves.
   Chris: Could make 'hyphenate-char' a shorthand for two properties.
   fantasai: Not really ncessary to make separate proeprties if they don't
             cacade independently. Just put two values in the property.

   howcome: One common knob is to not allow hyphen on last line. No property
            for that currently.
   fantasai: Can suggest in the spec that UA *should* not hyphenate the last
             line of the page.
   glazou: It is not a "should."
   <fantasai> People can ask for additional control in LC if they really
              feel it's needed
   glazou: 'hyphenate: auto avoid'?

   John: Need a way to indicate languages?
   fantasai: The lang= attribute.
   John: But then need language selector. Can also mark the hyphenate
         resource with a language.
   fantasai: If the doc doesn't indicate language, it will not be hyphenated.
   glazou: Why is the resource a property and not an at-rule?
   howcome: Possibly use different dicts for different elements.
   Dave: Could be a technical dict for special terms.
   fantasai: But glazou was asking if that can be a global resource.
   Steve: But if there are two languages?
   fantasai: Need to set a global resource *per language*
   Dave: Still need to suppress hyphens for certain elements.
   glazou: Can still turn it off per element with the main 'hyphens' switch.
   <fantasai> glazou's point is that there doesn't seem to be a need for
              setting dictionary resources per element, only per language
              per document
   Steve: Say I want math and chemistry, would need two dicst.
   [Discussion about wording: "try resources *in turn*, *in order*...]
   fantasai: Compares more  to 'font' or to @font-face'?
   Dave: But the math/chem example is only a problem if there is a word
         that it is hyphenated differently in them.
   Chris: LANG= allows extensiona fter the dash: en-chemical, etc,
   Steve: But then you ened to change your mark-up.
   Chris: But it probably belongs in the mark-up.
   glazou and fantasai draw on the board:
     @hyphenate-resource { en-us: url(en.hy); ... }
   howcome: What is the reason for at-rule over prop?
   glazou: Performance (only one, and fewer props) and conceptual.
   glazou: Performance is even a pb for batch processors, if style and doc grows.
   <dsinger> if you need to differentiate your danish-mathematics from
             your danish-chemistry because (for example) there is a word
             that is hyphenated differently in the two, I *think* you
             would be able to use a BCP 47 private use subtag, and still
             associate hyphenation rules and dictionaries 'globally' with
             a BCP 47 language tag
   glazou: Would you wait for a download of a dict when rendering an element?
   glazou: I want the at-rule to come before any other rules.
   [several: seems not important to enforce putting it first]
   Alex: I like the at-rule.
   Tantek: Seems indeed analogous to @font-face.
   howcome: How do you reference them in the style rules?
   Glazou: The 'hyphens' property switches hyphenation on and off.
   language settings associate the resources to the element

   glazou: Let's talk about other topics, time is limited.
   howcome: 'super-decimal' is a new keyword for list-style.
   [several: already added to list module at last ftf.]
   Chris: Refer to value of counter of a list item?
   howcome: Yes, target-counter()
   howcome: image-resolution...
   fantasai: Will move that to image module.
   Tab: I've been working on defining counter styles with at-rules. So far
       works for nearly all. No need for many predefined keyword anymore.
   Tab: Two or three are not regular and remain as keyword.
   Tab: All others can be defined with rules in the UA stylesheet.
   glazou: So GCPM should refer to that and allow at-rule-defined list numbers.
   howcome: But shouldn't make GCPM depend on something that has no clear
            time line.
   [General discussion about moving forward and dependencies...]
   * glazou likes the @counter-style at-rule *a lot*
   * TabAtkins My first draft at a UA stylesheet for all the list-styles:

   [howcome explains 'bookmarks']
   Tab: HTML5 has an outline algorithm. Does that interact?
   Steve: Independent.
   Steve: In PDF, anything can be put in a bookmark, it's not necessarily
          an outline. Could make a list of figures, for example.
   Tantek: That example should be in the spec, to make clear what bookmarks mean.
   howcome: Also, document not necessarily HTML, so not always defined how
            to make a toc from it.
   Chris: Yes, example of table of figures is good to add.
   howcome: The spec should not become an introduction to publishing, but
            some examples can be added.
   howcome: Bookmarks are not restricted to those examples.
   Molly: Show it with pictures.
   hakon: But careful that rendering is not necesarily the same everywhere.
   howcome: CMYK...
   fantasai: Didn't we decide to rename it to 'device-cmyk'? To stress that
             it is device-dependent.
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Jun/0186.html
   Steve: There are various specs, but different in several countries.
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Jun/0343.html
   dsinger: Can't you add a way to specify the desired color space?
   Chris: We had that discussion last time. howcome didn't want that at this point.
   howcome: I'd rather not change the notation. It's implemented and the spec
            is clear that it is device-depnedent.
   Chris: SVG has 'device-cmyk()'
   howcome: OK, then I will change it here, too.
   [David remarks that "this page intentionally left blank" should really be
    ... *nearly* blank. :-) ]

   howcome: Aligning baselines...
   Chris: Is this diff. from multicol?
   howcome: Yes, more advanced control over lines when there are images
            somewhere in the text, e.g.
   Steve: Also need that for page spreads. (Similar to columns.)
   howcome: Proposal here is to use 'line-box-contain' property from line
            box module (which is currently not being worked on).
   glazou: From the example, I can't understand what the property does...
   Steve: Easy enough to fix. Take Japanese, e.g., they need some sort of
          "snap to grid."
   Steve: So you need a way to define what the grid is and then say when
          you to snap to it.
   John: But nobody knows what a "line box" is.
   glazou: Is this baseline aligning only for multicol?
   howcome: Yes, although page spreads would be another application.
   Steve: It really only matters for the body font. Headers rarely need
          to be aligned.
   howcome: Another proposal than 'line-box-contain' was
   Steve: XSL has that.
   howcome: Yes, but XSL doens't have the 'grid-height' value that we need here.
   glazou: Would aligning baselines be the default behavior for columns?
   Steve: No, I don't think so.
   [Glazou draws on white board...]
   [Two columns, 2nd column has a big header in the middle.]
   howcome: You want to be able to force the lines after that heading to snap.]
   [Result shows last lines in both columns on shared baselines]
   glazou: That could also be done by setting some special kind of height/snap
           on that big element, rather than on the multi-column element a
           a whole.
   [howcome/Steve talk about other cases, Japanese, e.g., where that is
    not enough.]
   dbaron: I wrote 'line-box-contain' some years ago, there were reasons
          why it worked better than 'line-stacking-strategy', but I would
          need to study it again...
   dbaron: The former allowed, e.g., to choose explicitly what is currently
           quirks-mode behavior.
   Steve: I will need to ask in Adobe if this is too limited.
   ACTION steve: examine stack stacking, line box contain, and suggest a way
                 out of the problem.
   <trackbot> Created ACTION-257
   Bert: 'line-box-contain' also need a way to fix the problem of fallback
         fonts chaning the line box height, i.e., a way to specify that
         only the first available font influences the line box height.
   Bert: FF seems to do that currently, but it's not per CSS2.
   [10 min break]

Hit testing

   [Leif introduces the topic, writes on whiteboard...]
   Leif: Elements can overlap without one being descendant of another.
   Leif: Imagine that one has transparent background and below is one that
         expects click events.
   Leif: Depending on where you click and on the browser, you get different
   Leif: In some browsers, the transparent bg blocks events, in others not.
   <fantasai> isn't pointer-events supposed to address this?
   Leif: So we'd like to see a standard for it.
   Leif: Gecko & Webkit have a proeprty to specify behavior.
   Leif: Can even be more detailed.
   <dbaron> http://webkit.org/specs/PointerEventsProperty.html
   Leif: But important is that there is a common default behavior, less
         important *which* behavior it is.
   Chris: SVG has 'pointer-events' property.
   <ChrisL> pointer-events in SVG http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty
   dbaron: Yes, but it talks about things like 'stroke' and 'fill'. So we
          need a way to extend it to talk about CSS box model.
   dbaron: Dean had a proposal for how to do that.
   Tantek: I plan to work on that. Auto and none values seem interoperable,
           at least.
   <ChrisL> pointer-events
   <ChrisL>     Value:  	visiblePainted | visibleFill | visibleStroke | visible |
   <ChrisL>     painted | fill | stroke | all | none | inherit
   <ChrisL>     Initial:  	visiblePainted
   Tantek: 'Auto' needs more specification.
   Tantek: I just wanted to have 'auto' and 'none' for now.
   Anne: But there is hardly interoperablilty.
   Tantek: Two impls of those that do the same thing.
   <anne5> http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-events-20100820.html
   dbaron: Gecko/Webkit behavior is easy enough to specify.
   Tantek: 'auto' means the front element gets the event.
   Leif: Opera/IE  close to SVG's 'painted' value, Gecko/Webkit close to 'visible'
   dbaron: IE/Opera isn't really like 'painted'. They actually look at the
           shape of the painted text.
   dbaron: But not clear what the exact behavior is.
   Tantek: So what does Opera do?
   Tantek: Events include selecting text.
   Leif: Not sure what we do with that.
   Tantek: Current draft has basically the 'visible' behavior as default.
   <anne5> Hixie's draft: http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
   Leif: Hixie analyzed IE behavior a few years back. Opera used that as
         base for its behavior.
   Leif: Can IE switch? Since we have IE people here...
   Alex: I would need to look at what is happening now. I think we implement
         the property in some way, not sure what it does. It has the SVG values.
   JohnJ: Arron is testing right now...
   ACTION Arron: make a test for the pointer events behavior.

   Leif: I sent a text last Friday to www-style. Look for my name or for
         hit testing.
   <glazou> http://www.w3.org/mid/op.vhqsajuxtmo5g6@nynorsk
   <tantek> http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html
   Leif: I used Dean Jackson's spec. Mine has more comments.
   <tantek> http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-events-20100820.html
   Bert: Would all kinds of pointer event be handled the same, or is there
         different behavior for e.g., left click and right click?
   Tantek: No, all the same way.
   Tantek: I was planning to put 'pointer-events' in UI module and make it LC.
   Leif: Yes, that was my idea as well.
   Tantek: I want to make that module smaller, with only what has two impls.
   Anne: It is not currently in that module.
   Tantek: Right, I want to add it.
   Leif: Is that too quick? There is no good draft yet. Main interest for us
         is to have the same default behavior, less to have a property.
   Tantek: Would Opera be able to change its behavior.
   Leif: Yes, we would like to simplify.
   Anne: Some east-asian sites especially seem to rely heavily on IE's behavior.
   Anne: Gecko seems to have bug as well.
   dbaron: Yes, a known bug. No fix planned right now.
   dbaron: If there were a spec, we might be more willing to change behavior.
   <anne5> https://bugzilla.mozilla.org/show_bug.cgi?id=102695
   Tantek: So my new proposal is to put it in UI module, marked as "at risk"
           so that we can pull it easily before PR.
   dbaron: I want to get Robert O'Callahan's opinion.
   Anne: Need to define what element corresponds to (x,y) on the screen.
   David: The Firefox bug doesn't seem to get a lot of duplicates, so not
          a big problem at the moment.
   Tantek: I'll put in some simple prose absed on Dean's draft then. Until
           I hear more from you or from Arron's test.
   glazou: UI is not in our *current* charter. Can we publish an update
   Fantasai: A charter revision is possible, but since we're rechartering
             in a few months...
   Tantek: OK, I'll just work on the editor's draft and prepare it for LC.
   Tantek: Can still receive comments on it.
   [Discussion about speeding up the rechartering. Could recharter earlier,
    but then we can't put CSS2.1 in it as "finished"...]
   Chris: We'd need good text about CSS2 if we recharter early.
   glazou: That's doable.
   glazou: We already said Chris, Bert, Peter and me would work on charter
           in next three weeks.
   04:08 -!- Zakim [rrs-bridgg@] has joined #CSS
   RESOLUTION: try and move AC review of charter forward, to get UI module
               in it and publish a LC asap.
   <tantek> send new charter to AC by the end of September, with 4 weeks
            review, should be complete by end of October (in time for TPAC)
   Chris: We should inform SVG of the planned work.
   ACTION chrisl: tell SVG about planned work on pointer-events in CSS WG.
   <trackbot> Created ACTION-258

Styling Attribute Syntax

   Publish as CR?
   <tantek> http://dev.w3.org/csswg/css-style-attr/
   Tantek: What did the exponent issue have to do with this draft?
   Chris: CSS2 doesn't have scientific notation, so style attribute doesn't
          have it either. So SVG asked about that.
   fantasai: But is that an issue with this draft?
   Anne: Style attrib draft can refer to CSS latest state, not necessarily
         CSS 2.1.
   fantasai: Draft links to core grammar, which doesn't change anyway.
   <howcome> font-size: 2.6e-4em
   <TabAtkins> font-size: .00026em
   <TabAtkins> What's the difference?
   Tantek: Where in the style draft is the restriction?
   [Old discussion about scientific notation not needed.]
   David: style attr should not have a different grammar than full CSS.
   Chris: If you rewrite a stylistic attribute to a style attribute, you
          need to be able to allow everything.
   <dsinger> viewport-width 1.27e11 cm
   dbaron: This draft is not the place to change CSS.
   Fantasai: The draft carefully points to just the core grammar, nothing
             that restricts the attribute value to CSS2
   glazou: Draft cannot refer to documents that aren't CR, if it is to
           become CR or better itself.
   Tantek: Can Chris show the specific text to change?
   Tantek: This can go to CR as is.
   Tantek: If CSS's core grammar is revised, we can just make a quick
           revsion of the style attribute spec.
   fantasai: Changing the core grammar isn't not likely to happen anytime
             soon anyway. If it changes, we can update the style attr spec.
   glazou: Objections to CR?
   RESOLUTION: publish style attr as CR.

<br type="lunch" />

<howcome> Frank, who some of you met during lunch is responsible for
           specification documentation for Opera. Here are his documents

CSSWG Charter cont.
Scribe: TabAtkins

   glazou: I'd like to come back to the charter for a bit.
   glazou: Anne, what is the status/priority of the two specs you own?
           CSSOM and CSSOM View.
   anne5: View is still somewhat in flux, but getting progressively better.
   anne5: There have been requests for new features.  Hixie wanted
          scrollIntoView(), for example.  Also a few other legacy properties.
   anne5: It also has the Media Query api.
   anne5: Overall it's still in flux, but it's being implemented.
   glazou: So View remains in the charter, medium priority.
   glazou: And CSSOM?
   anne5: I thought I'd poll again recently to make sure there was value in
          the the Value API.
   anne5: It hasn't ever been published as a WD, but it's in the charter.
          It's still got a lot of red boxes.
   anne5: It's pretty high priority for me personally; it has a lot of
          necessary stuff.
   anne5: It does value serialization, getComputedStyle(), etc.
   anne5: For the Value API, I just need to invent something and hope
          it's good enough.
   glazou: So keep it in the charter, at medium priority.

Media Queries

   anne5: After MQ was done, I thought about defining MQ2, which defines
          both the query and the types so it can be truly standalone.
   anne5: Right now it depends on CSS2.1 and HTML4 for the definitions
          of several types.
   fantasai: That sounds like basically an editorial issue.

   glazou: So, next issue is MQ - issues, test suite, further steps.
   glazou: Anne, what's the status?
   anne5: I think I sent an email with my issues.
   <anne5> http://lists.w3.org/Archives/Public/www-style/2010Jul/0448.html
   anne5: With the test suite, there are a few things.  For one, it uses
          something moz-specific.
   ChrisL: What does it use?
   anne5: -moz-initial for font sizes.  I guess we can just remove it
          and use 16px.

   anne5: color-index doesn't appear to be implemented much.
   dbaron: The spec says that color-index should only work if you have
           an indexed-color device.
   dbaron: Which we don't support, so we always return false.
   ChrisL: Are there any impls that support a 256-color device?
   anne5: Personally I don't really know what the feature means or does.
   ChrisL: [explains color-indexed displays]
   ChrisL: Basically there's nothing *left* to test this on.  All the
           devices it could apply to are long past obsolete, like a
           black and white tty device that CSS also talks about supporting.
   TabAtkins: Can we just drop this, then, since nobody actually needs
               it and we can't do a non-trivial test?
   anne5: We could, but we have to go through LC again.
   ChrisL: I don't think there's a decent reason to drop it.
   anne5: So let's keep it then.

   anne5: Do we have guidelines for what the sourcecode of the tests
          should look like?
   ChrisL: Given that it's a single page, [something about the way the
           test displays results].
   dbaron: We could change the javascript up a bit to make it easier.
   anne5: We'll have two complete implementations very soon.
   ChrisL: So we can get an impl report out of it moderately easy?
   dbaron: Yeah, and we can tweak it if necessary.
   glazou: How many people reviewed these tests?
   anne5: dbaron wrote them and I reviewed them.
   glazou: On my Mac, safari is more fail than pass.  All green on Firefox.
   <glazou> http://www.w3.org/Style/CSS/Test/MediaQueries/20100726/media-queries-test.html
   glazou: ETA for all green on Opera?
   anne5: It's all parsing failures.  I can push it, but otherwise it's
          sorta near future.
   <anne5> http://dev.w3.org/csswg/css3-mediaqueries/
   <oyvind> (also missing support for dpcm)
   glazou: Next steps?  When can we move?
   glazou: So we just need implementation reports.
   anne5: I guess let's leave the tests as beta until we have one more
          implementation, then we'll push it as final.
   anne5: Then we can go to PR.
   arronei: Do we want a deadline set for reviewing?
   anne5: Nah, just fix the bugs.  Reviewing should just happen at the same time.

CSS Snapshot 2010

   RESOLVED: 2010 Snapshot is 2007 Snapshot + MQ.
   howcome: I think B&B should go in the snapshot.
   fantasai: We need to wait for a test suite for it.  It'll probably go
             into 2011.
   <fantasai> also, the spec isn't as stable as MQ either

Selector Serialization

   glazou: Next topic, selector serialization.
   <anne5> http://lists.w3.org/Archives/Public/www-style/2010May/att-0372/SSEL.html
   <anne5> http://lists.w3.org/Archives/Public/www-style/2010May/0372.html
   anne5: I don't have a problem with rewriting it; I'm not entirely certain
          I like this structure.
   glazou: It's just editorial work making it more coherent with how we
           describe selectors in the Selectors spec.
   <dbaron> my comments were http://lists.w3.org/Archives/Public/www-style/2010Apr/0452.html
   <dbaron> Tab's comments were http://lists.w3.org/Archives/Public/www-style/2010Apr/0382.html
   anne5: Ideally, I think serializing selectors and some hook into parsing
          a selector would go into the Selectors spec.
   glazou: Is that more relevant to the selectorText attribute in the CSSOM?
   anne5: There might be other things that need to use the serialization.
   anne5: Parsing and serializing seems like critical infrastructure that
          should be in the core spec.
   glazou: That would require moving Selectors in the priority part of the
   TabAtkins: Didn't we put Selectors 4 in Low Priority?
   glazou: Not yet.  We can.
   <anne5> (I didn't address your comment TabAtkins on selector serialization
           if you mean that.)
   Bert: I don't think we need another Selectors spec; second, selectors
         isn't about parsing or serializing.
   fantasai: If you don't implement the DOM, the conformance criteria
             should say that the OM stuff doesn't apply to you.
   <anne5> (I deferred them hoping for what we just agreed to :))
   glazou: We agreed to dispatch OM sections to individual drafts.  We
           absolutely need OM improvements - it's the worst part of CSS
           right now.
   glazou: Since it's only serialization, not new selectors, it can just
           be a revision.
   tantek: There'll be new selectors in CSS3 UI.
   fantasai: You might want to split that into a separate "UI Selectors"
             spec, so thinks like QuerySelector can refer to it without
             depending on all of UI.

Scribe: fantasai

   glazou: Next topic, Flexbox!
   <anne5> yay flexbox
   alexmog: We have an old spec and a new proposal; we have a number of
            very specific issues in the tracker I've opened which apply
            to either proposal.
   alexmog: Should we discuss where the spec is going, or the issues?

   dbaron: Additive flex is important to us
   Tab: I have several options for representing additive flex in addition
        to absolute flex
   Alex: There should be a very simple mapping from the old spec behavior
         to the new spec behavior
   Tab: One option is to have an additive flex unit
   Alex: One thing I liked about the old spec is that it's really really simple
   Alex: And it's exactly what you need for building UI
   Alex: Office UI is built with something similar to flexbox, or maybe
         even simpler than that.
   Alex: You can get lots of pieces built by different people put together
         in a coherent way only if the behavior is really simple.
   Alex: Don't want interactions with other things, margin collapsing, etc.
   Alex: I really liked the simplicity, and also the isolation from
         everything else
   Alex: The ability add a new module that adds really useful algorithms
         without complexifying everything else.
   Tab: All it's essentially doing is taking the abilities in the current
        draft, and generalizing them slightly.
   Tab: There's no interaction outside the flexbox container.
   dbaron: What happens to flex units outside a flexbox?
   Tab: It would have to default to something. Haven't figured that out yet.
   dbaron: That's a concern I have is that the flex units leak out
   Alex: There's a temptation to apply flex units outside the flexbox model
   dbaron: e.g. flex margins in abspos
   Tab: We totally want that
   Alex: I would like to come up with Grid very soon. If you look at ...
         Grid and Flexbox play together very nicely.
   Alex: I would hope that other layout models interoperate with flexbox as well.
   Tab: you can have flexboxes spill into multiple lines, sortof like a table
   dbaron: XUL has a grid model, but it's not in the flexbox spec
   Tab: You could do a XUL-type grid in flexbox easily
   Tab: You could also use flex concepts in Template Layout, where it would
        be very useful.
   howcome: I'm hesitant to define units that are only useful within a
            specific layout algorithm
   fantasai: You'd want to specify exactly which properties accept
             flex. e.g. text-indent should not take flex units
   <dbaron> text-indent flex would be like text-align-first: end
   <Bert> (Me thinks, on the contrary, a fexible text-indent would be
          very nice: can have the last line of the para flush with the
          right margin that way... :-) )
   Alex: I considered having Grid do layout computations similar to flexbox
   Alex: .. specify width of multiple columns, without defining some kind
         of flex unit
   Alex: Also it would be useful for flex units to not complicate ...
   Alex: Maybe there is a compromise where there is a flex unit that can
         be parsed into a grid unit, but can't be parsed into a length.
   Alex: Currently in grid positioning, there is an fr unit that only
         applies to that feature
   Tab: I want to apply flex to margin/border/padding/width/height
   Alex: maybe you could have a different property that specifies a
         flexible margin
   Tab: I don't think it makes sense to add ... to avoid having flex
        units in the margin
   Alex: margin is a way for flexbox to spill outside the flexbox
   Tab: The use of flexes is only defined within the context of flexbox.
   Alex: ... isolation.
   Tab: If you were to use a flex unit outside a flexbox, it would
        compute to a used value of zero
   fantasai: or maybe even a computed value
   Tab: I understand your concern about the application of flex to
        normal flow, but I don't think it is actually a problem.
   Alex: If that's the only thing we are disagreeing on, we're doing
         pretty good.
   Alex has some concerns about syntax of various properties
   Tab: Could probably get a test impl in Webkit
   dbaron: One other thought about the units is maybe we want some
           other type of value within the property that's not a unit
   <dbaron> could we do something like height: flex(1) [non-additive]
            or height: 50px flex(1) [additive] ?
   Alex: I would prefer that slightly over a general unit
   Alex: It's obviously not a length
   Alex: It's something specific
   Alex suggests adding an additional set of margin properties for
        flexible margins
   fantasai points out that this is a cascading nightmare, and would
            be confusing to authors because they would think they're
            resetting margins (e.g. to zero) when they've only reset
            one set of margin properties, the other set of which still
            has some other values
   * fantasai is strongly against a new set of properties for margin therefore

   <TabAtkins> http://www.w3.org/Style/CSS/Tracker/issues/open

   ISSUE-138: http://www.w3.org/Style/CSS/Tracker/issues/138
   Tab: Is this similar to the way abspos inside tables is handled?
   Alex explains the proposal
   fantasai: yeah, that's just like tables
   dbaron: We've institutionalized placeholders now.
   Tab: It makes me sad, but yeah.
   RESOLVED: Out-of-flow elements use placeholders during flexbox construction

   ISSUE-139: http://www.w3.org/Style/CSS/Tracker/issues/139
   Alex: Next issue is what reversing pack: start does
   dbaron: The whole pack-align-direction stuff is probably one of the
           more confusing things in the current spec
   dbaron: The current proposal still has box-direction?
   Tab: It does have display: flex
   Tab: and it does have direction. It takes two directions, one for
        the main flow
   Tab: Another for which side they're placed on
   fantasai: So you have like an inline-progression-direction and a
   dbaron: how do you justify the boxes in the transverse direction?
   Tab: You give all the boxes a flex of one
   Tab: auto heights and widths evaluate to one flex on flexbox
   dbaron: In transverse direction?
   Tab: yes
   dbaron: ok, that solves it

   ISSUE-140: http://www.w3.org/Style/CSS/Tracker/issues/140
   dbaron: min/max widths assign intrinsic widths, rather than assigning
   dbaron: in Mozilla's implementation
   Alex: At which point do you apply min/max height?
   Alex: in the primary direction, I thin it should have its normal meaning
   Alex: So we've run all of the normal algorithms
   Alex: And then max it with max-width and height, redistributing
         available space if necessary
   dbaron: Which is the same problem you'd have with height in a
           fixed-height environment
   Tab: Horizontal flexbox, max-height on one of the flexbox children,
        and box-align: stretch.
   dbaron: Ah, the table problem
   Tab: And one of the children is taller than the max-heights
   Tab: Everyone wants to stretch to the height of that child
   Tab: Do we honor the max-height, or do we ignore it
   dbaron: Or shorten the parent
   Alex: I think shrinking the parent is the worst option
   dbaron: I think it's the best option
   Tab: You wouldn't want to do that if box-align is start.
   Tab: So it's really weird if we apply max-height to the flexbox parent
   Alex: I prefer an approach where everything is normal, and whoever
         chooses to have a max-height just becomes smaller
   Alex: I don't think it matters where it aligns
   Tab: It has to be defined
   Tab: And I would like to control that
   fantasai: So allow stretch + a direction
   Alex: I prefer start being the default alignment
   Tab talks about vertical alignment within the box
   Bert suggests using 'vertical-align' just like in tables
   fantasai: or flex the padding
   fantasai: I'd suggest centering by default
   discussion of directional terms
   transverse direction and progression direction?
   <Bert> (Tab's gestures suggest "wavelength" and "amplitude" :-) )
   dbaron: I lean towards centering as well
   JohnJansen: me too
   Alex: But the contents align to the top by default
   Alex: It looks odd to center the box, but top-align its content
   Tab: Yeah, that makes sense
   Tab: to keep those two consistent
   RESOLVED: max-width/height restricts the size of a flexbox child
   RESOLVED: If a box is shorter than its row, it is aligned as
             if box-align: before.

   ISSUE-141: http://www.w3.org/Style/CSS/Tracker/issues/141
   Alex: Need to define the baseline of the flexbox
   inline-blocks it's the bottom line
   inline-table it's the first line of the first row
   Alex: Should aligning contents of flexbox to the baseline align the
         same way as table cells, or something different?
   dbaron has a preference for copying inline-block
   dbaron: Part of the reason inline-table works the way it does is
           because vertical-align: baseline on table cells uses the
           first line
   dbaron: and given you're using the first line, you might as well
           use the first row
   Alex: The most common case for flexbox would be form controls
   <Bert> (http://www.w3.org/TR/2002/WD-css3-linebox-20020515/#inline-box-align
          allows to select which line is the line that determines the baseline.)
   Alex: They will usually be only one line of flexboxes
   Alex: but you do want baseline alignment
   dbaron: You first line when you have a flexbox with a checkbox and
           a multiline label fo rit
   <dbaron> (or center, in which case you're not doing baseline
             alignment at all)
   Tab: So let's go with inline-table model
   Alex: My implementation uses the first line of the first item
   Alex: It's super simplistic, but I'm still looking for a case where
         it wouldn't be a good choice
   dbaron: the one case it might not be reasonable is if you have a
           bunch of flexboxes that are baseline-aligned to each other,
           but the first item isn't
   Tab: In the current draft, the alignment has to be the same for all
        flexobx children
   dbaron: I guess that's not a problem then
   <dbaron> except it is a problem in Tab's draft
   <dbaron> since he uses vertical-align, which goes on children
   Tab: But in my draft, you do vertical-alignment by applying
        vertical-align to each flexbox individually
   Alex: Do we agree on doing first line of first item?
   Alex: And if we find cases where it's not a good choice we'll add them
   <dbaron> (might want to check if any boxes have baseline alignment first)

   <TabAtkins> http://www.w3.org/Style/CSS/Tracker/issues/142
   <trackbot> ISSUE-142 -- Does box-ordinal-group change drawing order? -- open
   <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/142
   Alex: So Appendix E
   Alex: There is a few options
   Alex: One is getting rearranged throught the ordinal group
   Alex: either draw in source order or layout order
   Alex: Argument in favor of layout order is that it's more visually expected
   Alex: Minor inconvenience is it will need an update to appendix E
   Alex: Other issue is if we get to 2D flexible grid
   Alex: It is less clear what order to paint, and source order makes more sense
   dbaron: I think Appendix E should refer to order in the box tree
   dbaron: And I think box-ordinal-group should change order in the box tree
   dbaron: so I think we're done
   Alex: So let's use layout order
   Tab: I think that's the right source, and ordinal-group should rearrange
        the box tree
   RESOLVED: Flexboxes drawn in layout order (as altered by ordinal-group).

   Tab: I don't currently have ordinal-group in my draft. bz doesn't like it.
        Are we still down with it?
   dbaron: Our implementation is a little flaky. We only started using it
           for really critical stuff in this Firefox release
   Tab: His problem was that if you have a large group, you have to run
        sorting algorithms on it
   * Bert considers 'box-ordinal-group: alphabetic', good to make an index...
   fantasai: Might want to note that authors should avoid doing that if
             they want to avoid perf problems...
   Alex: I imagine someone sorting icons in the filesystem by assining
         filesize to box-ordinal-group...

   <dbaron> issue-143?
   <trackbot> ISSUE-143 -- Does "shrink-to-fit" width of a flexbox child
              depend on available space? -- open
   <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/143
   Alex: Is the pref width max by available, or not?
   Alex: I believe in Mozilla it isn't
   Alex: Given we're going to adjust that later with flex, it makes more
         sense to lay out in infinite width
   dbaron: The issue here seems to be that WebKit is using fit-content
           where it should be using max-content
   dbaron: I think we do want to use max-content
   Tab: Ok, let's track Mozilla behavior here.
   <dbaron> I can't really think of any use cases where this makes a big
            difference other than the text-in-tables type issue
   RESOLVED: Use max-content for preferred width in flexbox sizing

   <dbaron> ISSUE-144?
   <trackbot> ISSUE-144 -- distribution of negative available space -- open
   <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/144
   Tab: How we distribute negative space.
   Alex: currently, the exact same algorithm that is used for positive
         space is applied to negative space just with a negative sign
   Alex: So if an item has a bigger flexibility, meaning it's greedier
         and wants to get more extra space available, then it will get
         significantly less space if there is not enough space.
   Alex: I'm having a hard time finding any situation where it's useful.
   Alex: For example if you have a lot of text in one box and not much
         text in the other, they'll balance in a way that's completely
   Tab explains some algorithm
   dbaron: what if one has flex 1 and the other has flex 2
   fantasai: I don't think the one that's supposed to be twice as wide
             as the other should wind up half the size of the other
             b/c we don't have enough space
   ... TeX
   dsinger: You should study the TeX glue model
   dsinger: Knuth solved this pretty solidly so you should go look at that
   Alex: We should either ignore space when availspace is negative
   Alex: and distribute some other way
   Alex: Or have a separate value that is how to distribute when negative
   dbaron: There are some cases where you want to distribute space in
           proportion to its flex
   dbaron: e.g. you have two groups of flexboxes, one with 4 children
           and one with 2, and you want to distribute the extra space
           evenly among all the grandchildren
   dbaron draws a box with two boxes inside it
   one of which has 2 boxes inside, the other of which has 4 inside
   dbaron: In a case like this you do want to maintain flex ratio when
           distributing negative space
   Alex If you shrink, you want to shrink proportionally to the amount
        of text ....
   Tab: If the flex is proportional to their preferred widths.
   Tab: When the flexes and preferred widths don't match, that's when
        you get the non-intuitive results.
   dbaron: Maybe completely ignoring flex is fine
   <dbaron> (when shrinking)
   Tab: And shrinking in proportion of their preferred widths is fine

   <dbaron> ISSUE-145?
   <trackbot> ISSUE-145 -- inline-block children of flexbox -- open
   <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/145
   fantasai: The spec should say 'inline-level elements' and then it's
             completely clear.
   Tab: The spec groups inline elements together
   Alex argues that inline-blocks should become individual items
   dbaron: I think you at least want to group text and true inlines
   Arron: whitespace?
   Tab: just like tables
   Alex: I want a model where flexbox with a bunch of buttons in it
         doesn't require display:flex on all the buttons
   dbaron: I'd be fine with saying that you'd only wrap text and
           *non-replaced* inlines.
   fantasai: Ok, so you want atomic inline-level elements to get
             individually wrapped, and non-replaced inlines get grouped

CSS2.1 Issues

   fantasai: Issues 158, 159, and an unnumbered issue are all about
             margins and clearance.
   The original issue that caused this was issue 6.
   TabAtkins: We really need to talk to Michael (Arron's coworker)
               about this.
   ACTION arron: Talk to coworker about proposed clearance changes.
   <trackbot> Created ACTION-260
   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-158
   fantasai: Info about these issues was sent to the list.
   <fantasai> with proposal http://lists.w3.org/Archives/Public/www-style/2010Aug/0458.html
   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-159
   <fantasai> with proposal http://lists.w3.org/Archives/Public/www-style/2010Aug/0391.html
   <fantasai> 158 and 159 should be editorial

   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-195
   <fantasai> back to 195
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0462.html
   dbaron: For issue 195, you could maybe say it divides it into two pieces,
           one on either side of the block?
   Bert: The original problem was if one side was empty, like
         <span>foo<div>bar</div></span>.  The new text doesn't seem
         to clarify this yet.
   Bert: Perhaps add an "even if either side is empty"?
   fantasai: Sounds good to me.
   TabAtkins: Sounds good.
   RESOLVED: Proposal accepted for CSS2.1 Issue 195 with edit above.

   fantasai: The other issue I editted was the bidi one.
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0465.html
   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-187
   TabAtkins: You have two possibilities in that proposal.  Do you know
               if either should be preferred for compat reasons?
   Bert: The "atomic inline" one seems easier.
   fantasai: One wrinkle is that if you replace an image with its alt text,
             the bidi ordering may change.  The more complex first option
             takes care of that and prevents it from changing.
   Bert: I'm not sure I understand what the "replaced element that would
         be inline if not replaced" means.
   TabAtkins: An image, for example, will be replaced by ordinary alt
               text if not available.
   fantasai: The wording is to deal with the case for when you can have
             either text or a replaced element.  If you set an explicit
             embedding level and there's text, then the surrounding
             content will be affected by the direction of the embedding.
             If it's a replaced element and you define replaced elemenets
             to be neutral, though, then the replaced element won't have
             the directionality from the embed.
   fantasai: So now if you set unicode-bidi on the <img>, it'll affect
             how the surrounding text is ordered, in the same way
             regardless of whether it's a replaced element (image) or
             not (text).
   Bert: There's a parenthetical about run-ins?
   fantasai: That's why the wording is so weird, specifically to handle
              runins, or else I'd just say elements with display:inline.
   fantasai: It seems that no one disagrees in principle with this,
             they're just confused by the wording?
   Bert: It's very confusing.
   arronei: Agreed.

   <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0448.html
   szilles: I thought of a problem with my suggested fix for issue 198,
            but I can't recall it exactly right now.
   ACTION Steve: Respond to yourself about issue 198.
   <trackbot> Created ACTION-261


   howcome: Multicol moved into CR and has 6 implementations!
   howcome: They have a baseline level of compatibility.
   fantasai: Probably pagination issues will be the worst.
   howcome: What I'd like to spend time on is to fix two problems in the spec.
   howcome: 1) We don't really define how column rules behave when the
               content doesn't fit nicely.
   howcome: 2) We copied the border-style values from the border property,
               but some of them don't make a lot of sense in terms of
               columnn rules.
   howcome: double/solid/dashed/dotted/none make sense. I don't know about hidden.
   dbaron: hidden only exists for the collapsing border model in tables.
   howcome: I think we should remove inset and outset.
   howcome: They come from buttons for a pseudo-3d effect.  But with
            columns you don't have that.
   glazou: I don't think we should remove values because otherwise you lose
           consistency with border-style
   fantasai: You should make it work like the collapsed borders model
             and treat them like ridge and groove.
   dbaron: Except that we got the spec backwards in collapsed borders years ago.
   <dbaron> actually border collapse is the right way round
   fantasai: I think that inset/outset it isn't clear what's supposed
             to happen, so just go copy what the border-collapse thing does.
   howcome: That's an easy solution.
   RESOLVED: Use border-collapse border-style behavior for column rules.

   howcome: Next issue is column rules.  They're drawn between columns, and
            are the currently the height of the multicol element.
   howcome: So even if something overflows, you don't have column rules
            going down to it.
   howcome: I think that if we extend, we don't want individual rules to
            extend individually.
   howcome: But then you have long column rules sticking out the bottom for
            seemingly no reason in the rest of the multicol.
   howcome: Also, there's a question of if you should draw rules between
            columns that that overflow the multicol horizontally.
   howcome: Robert argues on the list that you should treat them the same.
   howcome: But also maybe it looks more elegant to keep the rules horizontally.
   [everyone agrees that it looks better to show them horizontally, cut
    them vertically]
   howcome: Also, what if people make column rules that are super wide
            and would overflow the content?
   [agreement that authors should be allowed to do that if they feel like
    it, don't try to clip]
   RESOLVED: Column rules are not clipped by the multicol element horizontally.

   fantasai: What's the stacking order for column rules?
   <fantasai> s/just above the background/immediately below the border
                                          (above the background)/
   howcome: Cool.

   alexmog: If you had only two columns, there'd only be one rule and
            nothing outside the box (in your example)?
   howcome: Yes.
   szilles: If it's balanced columns in an element with sufficient height
            that there's a gap at the bottom of each column, does the
            rule extend all the way to the bottom of the multicol, or
            only to the bottom of the content?
   howcome: The spec says to make them the full height.
   [agreement, looks good]
   howcome: though I think we might want to add border-clip ability to
            rules at some point
   alexmog: Word doesn't extend it to the bottom of the element, but
            we can use height:auto to simulate the behavior, so we're okay.
   RESOLVED: column rules are drawn to the height of the multicol element
   howcome: Also, rules are only generated between columns with content.
            If the element is wide enough to hold 5 columns, but there's
            only enough text to fill 2, only a single rule is generated.

   <Bert> ISSUE-129?
   <trackbot> ISSUE-129 -- balanced columns in fixed-height -- open
   <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/129
   howcome: [draws a diagram with 3 columns.  An h2 is col-span:all in
             the middle, with text above and below it.]
   alexmog: Conceptually, the text above the h2 comes before it in the
            source, text below it is after it in the source.
   alexmog: Now what if you have even more content, so you have overflow
            columns, and another h2 with col-span:all in that section?
   dbaron: Maybe col-span:all should be cancelled on overflow sections?
   alexmog: If you say that setting overflow makes new columns to the
            right, *unless* it's balanced and doesn't fit, that's an
   alexmog: If the content fits and there's extra space, extra space is
            distributed betweeen columns.  If there's not enough space,
            there's no balance - it just fills what it needs and overflows.
   fantasai: I don't know if I like that.
   [pagination discussion - how multicols work in paged media]
   dbaron: Why do we allow column balancing in a fixed-height container?
   howcome: I think it looks nice.
   alexmog: You might have a paged implementation where you want to
            balance the last page.
   howcome: Also if you have a min-height or max-height, it could
            suddenly stop balancing because the content got too large.
   [back to colspan discussion]
   [colspan gets turned off if the element is in an overflow situation]
   dbaron: That content ordering is crazy.  Would anyone ever want that?
   dbaron: I'm also not sure it makes sense to have a colspan on in fixed
           height columns.
   alexmog: It makes lots of sense in a paged situation.
   * Bert thinks 'div.article {overflow: auto; overflow-style: paginate}' --
          makes flippable pages, instead of a scrollbar or something else
   howcome: I propose we go with alex's suggestion.  col-span:all only
            spans the visible column, and colspans in an overflow column
            don't colspan.

   dbaron: What I want to say is that colspan doesn't do anything if your
           column is fixed height.
   dbaron: The case where you're actually doing fixed-height columns,
           you're not wanting actual colspans.
   TabAtkins: What about paged media?
   dbaron: I'm distinguishing fixed height from paged media.  They work
           differently, and won't cause a problem.
   fantasai: How about columns overflow downwards?
   TabAtkins: In multiples of the original height!
   fantasai: But an original use-case was specifically to flow columns sideways.
   fantasai: And we resolved on that.
   TabAtkins: Maybe a property at some point to specify how multicols should
              place their overflow columns.
   szilles: And that solves dbaron's issue, I believe, if you overflow them
            downwards in a "paged" fashion.
   dbaron: Yeah.
   howcome: I think we don't want to add anything for the vertical overflow
            yet.  We'll just go with alex's proposal.
   <dbaron> I still don't think anybody has shown any reasonable case that
            would be disabled.
   RESOLVED: Use Alex's suggestion for disabling colspan on elements located
             in overflow columns.


   <smfr> ooh maybe i should call in
+smfr over a sketchy telephone connection
   <fantasai> http://dev.w3.org/csswg/css3-background/#the-box-shadow
   <tantek> (phone rings)
   dsinger: we want a note saying something about half the standard deviation
   dsinger: as long as we don't talk about the edge of it
   fantasai: I took some of the text and put it into an explanatory note -
             visibly apparent color transition ... twice ... fully transparent
             at the edge outside it.
   tab: we're no longer referring to the edge of the blur because that doesn't
   <fantasai> A non-zero blur distance indicates that the resulting shadow
              should be blurred, such as by a Gaussian filter. The exact
              algorithm is not defined; however the resulting shadow must
              approximate (with each pixel being within 5% of its expected
              value) the image that would be generated by applying to the
              shadow a Gaussian blur with a standard deviation equal to
              half the blur radius
   <fantasai> Note this means for a long, straight shadow edge, the blur
              radius will create a visibly apparent color transition
              approximately the twice length of the blur radius that is
              perpendicular to and centered on the shadow's edge, and that
              ranges from the full shadow color at the endpoint inside the
              shadow to fully transparent at the endpoint outside it.
   tab: ... two standard deviations and that's really easy
   tab: at the blur radius ... 97%
   q&a between jdagget and tabatkins
   <smfr> this phone is terrible
   <smfr> i'm fine with the current spec btw
   tab: 97% isn't even the point where it hits 100% transparent but I've
        found thru experimentation, the difference between those two is
        pretty big, to the point where the shadow looks smaller than it should.
   <dsinger_> I think 2*sigma is actually 95%
   tab: if you want the shadow to extend out....
   <fantasai> visibly by the amount of the blur radius
   * dsinger_ see 'standard deviation and confidence intervals' at
   tab: dsinger you're right, 95% lies between both sides, but in this,
        we're looking only at one side which is ~97% from there
   fantasai: if everybody is happy with current text we can resolve this issue
   jdaggett - it may affect pixels beyond
   tab: it will
   dsinger: if I'm running on a 16 bit system...
   tab: but even there, you won't be able to see ...
   jdaggett - I would watch that assertion - with the right color and
              background you will see it for a long way
   jdaggett - if you have issues where the surrounding geometry is very
              distinguishable, you'll be able to see it more.
   szilles: isn't this an implementation issue?
   tab: within the bounds it is safe to drop to full transparency at that
        point. if you wanted to you can do that. it's just not required.
   <anne5> http://dev.w3.org/csswg/css3-background/#the-box-shadow
   (skype discussion for getting another person on the phone)
   <smfr> don't they have conference calls in norway?
   <anne5> we use telepathy here
   <glazou> vikings use empty bottles of aquavit only
   (bert sets up zakim)
   (static on phone, laughter)
   <smfr> btw i have to leave early again
+bradk over sketchy telephone connection

   fantasai: we have another topic, which is the stacking order of the
             inset shadows
   fantasai: the proposal that came in was that the inset shadows should
             be painted *above* replaced content, so we asked why not
             all content to be consistent
   fantasai: the proposal is to paint the inset shadows above the content
             layer, but not z-index things
   dbaron: so if you have an inner box shadow it overlaps the text in
           the box?
   fantasai, tab: yes
   dbaron: ok
   <smfr> i don't like this proposal
   <smfr> it has stacking context implications
   fantasai: the z-index lets you pop things out and bring them forward
   tabatkins: children with a higher z-index are painted above
   dbaron: you want to say it in terms of [CSS21] appendix E, not in terms
           of z-index
   <smfr> agreed
   fantasai: it's a lot of layers so you need something more precise
   fantasai: it's between layers 8 and 9
   dbaron: you don't want to say it that way either
   <smfr> http://www.w3.org/TR/CSS2/zindex.html
   fantasai: 8 & 9 in the sublist of 7
   fantasai: not it is top level 8 & 9 - not sublist
   <smfr> so does an inset shadow make the element a stacking context?
   dbaron: we need a new top level paint layer for inset box shadows
   dbaron: if you put it above rel-pos things, it's not just above
           rel-pos things in that element, but also above rel-pos things in ....
   dbaron: that top level list is what to do for each stacking context
   dbaron: for each stacking context you paint ... i'm trying to think
           about what this means
   <bradk> My connetion is bad, but would it be possible to only paint
           above the content when there is non-visible clipping?
   dbaron and fantasai discuss
   <bradk> That would also make it look best with things that protrude
           outside due to negative margin, etc.
   fantasai: where is a block child painted ... here....
   <smfr> so if you paint the shadow above the content, think about what
          things look like with overflow
   <smfr> borders draw under the content
   dbaron: you can stick it in point 3 or 4 in sublist 7
   <smfr> if the shadow draws on top, it's just weird
<smfr> gonna drop off the phone; it's useless
   <smfr> also, doesn't this mean that the inset shadow draws above the border?
   <fantasai> So the proposal is to paint inset shadows immediately
              below the outline.
   <fantasai> And yes, this would have the side-effect of drawing the
              shadow above a border-image
   <smfr> i think this is weird
   <fantasai> (since it will never overlap with the border)
   <smfr> i think the shadow should be between the background and the border
   <dbaron> sylvaing, Zakim bridge?
   tab: if you're having the border-image extend into the box - that's
        how it works
   <smfr> if it's just under the outline, then you've lost the "pop out
          with z-index" trick
   <bradk> TThe call quality is like listening to a tin can
   <smfr> so the shadow will draw over abs pos, z-index children, which
          is also weird
   tab: the point of having box-shadow back into the draft was having
        something simple that we could accomplish now
   <smfr> i'm with tab; we're making too many changes to box-shadow at this point
   <bradk> smfr, can look good if you have light colored items inside a
           scrollable box with inset shadow.
   <dbaron> I'm with smfr
   tab: "i'm with you you're wrong"
   dbaron: I'd really like to get box-shadow unprefixed
   dbaron: we're going to ship FF4 with box-shadow to indicate invalid
           form fields, and authors are going to want to turn it off,
           and they're not want to going to use a prefixed property to
           do that
   fantasai: So you either get inset shadows over the content, or you get
             it under the border-image. You can't have both.
   <smfr> yep
   fantasai: Unless, perhaps, you have two different inset-ing keywords,
             one which paints at one layer and one which paints at another.
   <smfr> ugh
   fantasai: and we could add the other keyword in CSS4 Backgrounds and Borders
   tab: so no change to box-shadow now, but plans for v4 that will somehow
        draw intelligently on top of content
   <bradk> Overflow can be the trigger
   <smfr> or wait for future filtery things
   tab: overflow could be the trigger
   tab: brad, could you explain what you mean?
   brad: if overflow is the trigger, then if you have a scrolling box with
         a shadow, then the content should be inside underneath... hello?
   tab: .... --- .... ----
   <smfr> i think interaction between different properties like that
          should be discouraged
   <sylvaing> it sounds like we're trying to make inset more 'realistic'
              and I'm not sure why it should be more so than other aspects
              of the feature
   brad: when i did an experiment with box-shadow on a scrolling box
   brad: it looks kind of strange to have the shadows behind the content and
         scrolled out of view - it just doesn't seem natural
   tab: this might be trying to make box-shadow too realistic
   tab: in the mean time we do nothing. we recognize the use-case, but not
        with box-shadow
   <sylvaing> agrees with tab; if we want realism the feature already has
              many shortcomings
   tab: inset box-shadows above the background layer - what they do now,
        below the content
   <TabAtkins> I think that the above-content shadow makes scrolling look
               a lot better, but I don't think it's a good trigger for the
               new shadow.  I don't like that kind of interconnection.
               Also, it won't solve the basic problem of images.
   <sylvaing> unclear why inset needs to be more real than the rest
   <TabAtkins> Agreed, sylvaing.
   <sylvaing> is comfortable with a simple decorative effect
   fantasai: they are using it for glowy effects, lightbox
   <sylvaing> but is not a designer either. argh.
   <TabAtkins> I think we're best off by saying "We'll solve this
               *properly* with filter effects; box-shadow is
               supposed to be really simple"
   <bradk> It is not so much that I want super realisom, it is that
           scrolling things outside the box tends to destroy the effect
           of it being a rectangle cut out of the canvas.
   <bradk> It really looks pretty weird when you do that, IMO
   <fantasai> bradk: if it paints over the content, it has to paint
              over the border-image
   <fantasai> bradk: so there's an unfortunate tradeoff here
   <bradk> Agreed it is unfortunate. But in my way, it would be
           limited to when you have overflow:[not visible]
   <bradk> And that can be turned on and off for a lot of content
           without much other noticiable effect
   <fantasai> bradk: I think we have consensus that that kind of
              out-of-left-field trigger is a bad idea
   <fantasai> bradk: If we want a trigger, it should be in the
              box-shadow property itself
   (tab makes an example)
   tab: scrolling with a box-shadow does look bad
   tab: oh wait - it's fine
   tab: this is right, the shadow shouldn't scroll
   <bradk> It's just that, with overflow:scroll, for instance,
           that it almost always looks wrong, unless all the
           content is black.
   <TabAtkins> data:text/html,<!doctype html><div style="width: 100px; height: 100px; -webkit-box-shadow: inset 5px 5px 10px 
black; overflow:scroll; color:red;">foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo 
foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo</div>
   <TabAtkins> fantasai: I think Brad's right - it will look bad
               in a *lot* of cases.
   <anne5> (WebKit only does box-shadow prefixed)
   fantasai: then we have the implementation issue that people
             want to drop prefixes
   <sylvaing> it looks bad in a lot of other cases too
   <bradk> Now make even bigger blurrier shadows in that example...
   <sylvaing> e.g. when background-color is transparent and you
              can't see the shadow underneath but can see the
              body background-color
   Håkon introduces David of Opera who is implementing box-shadow
   <sylvaing> the feature already has a very limited scope
   David: I think I agree with what you're saying
   David: we should leave box-shadow as it is
   <sylvaing> yet there is no doubt that it already is useful to authors
   <TabAtkins> sylvaing: Yeah, I think that's the thing.  Sure,
               it's rarely useful as-is, but you can't fix it
               *properly* without a lot of work.
   <anne5> (Opera currently does box-shadow unprefixed)
   <bradk> What is the downsde of an overflow trigger?
   tab: with scrolling it looks really bad, but ehhh, doing it
        properly - there's more cases that can be relatively
        common, that will also look bad, and we'll also have
        to do more stuff to make them look good.
   <anne5> (Gecko prefixed)
   tab: with repairing this issue, a majority of things will
        still look bad with inset box-shadows
   <sylvaing> tab, yes. I too wish it were more useful than
              adding a shadow to a custom button control and
              the like. but it turns out that as simplistic
              as it may be, it is very useful. we might already
              have 80% of the feature.
   tab: that's just how it is, we'll do it properly later
   <bradk> Just limits border-image in overflow inset-shadow
           situations, as upposed to all overflow inset-shadow
           situations looking weird
   fantasai: we can put both definitions in the spec, with
             different keywords and mark them both at risk.
   <fantasai> we mark both inset and inner shadows as at risk
   <bradk> Then you could properly fix it for border-image
           later and have a good default now?
   tab: acceptable to you dbaron?
   tab: add another keyword for the additional behavior and
        mark it at risk
   dbaron: i'd rather not keep adding stuff
   <smfr> i don't want a new keyword at all
   dbaron: two years ago we wanted to be done
   <sylvaing> agree with dbaron and smfr
   <tantek> we can always add a new keyword later if someone
            has a solid proposal
   fantasai: we have a solid proposal
   fantasai: what you want to do to make everything look supercool
             is to put content on the shadow and border-image and ...
   tab: hopefully someday filters will let us do this (like IE4 filters? ;) )
   tab: we want something like that
   <bradk> That might be supercool, but I'd settle for reasonable
           in the majority use cases
   <tantek>: URL for said solid proposal?
   <fantasai> Proposal is to have an 'inset-overlay' keyword that
              behaves just like the 'inset' keyword except the
              shadows it generates paint immediately underneath
              the outline layer (when it is not painted at the
              #10 option in Appendix E)
   <fantasai> RRSAgent: pointer
   <RRSAgent> See http://www.w3.org/2010/08/24-CSS-irc#T15-23-35
   <fantasai> there's your url
   <tantek> so noted
   tab: that's what we want to do
   fantasai: nothing right now?
   tab: nothing right now
   håkon: let's go to CR
   <Ms2ger> Håkon++
   <bradk> I'm hearing that 'inset-overlay' would be "at-risk"
           (code for "never to be implemented")
   <sylvaing> howcome++; this is about adding a simple shadow to
              that facebook dialog that confirms you have given
              up on all your privacy (again). Not accurate 3D
              rendering of the stacking context based on the
              sun's position. Ship it !
   <bradk> True?
   <TabAtkins> bradk: No, we're just not going to do it at all right now.
   * TabAtkins wants a physically accurate rendering based on the
               simulated position of the sun.  Using geolocation.
   <bradk> It is really only in overflow situations that it bothers me,
           and then almost always in those situations
   * sylvaing yeah, well. bite me.
   <bradk> Come on, I'm not asking for ray tracing
   * dbaron reminds TabAtkins that that requires geolocation,
            gravitometer, and compass :-P
   (slightly more furious typing)
   Bert: so is the resolution CR?
   Bert: I'm waiting for the chair
   * sylvaing lives in Seattle, where shadows are a completely abstract concept
   <bradk> Well and in some replaced objects too
   glazman: absolutely
   RESOLVED: publish as CR
   <TabAtkins> bradk, I know, but it's still a decent chunk of complexity.
               And we really want B&B to go CR.
   <TabAtkins> bradk, B&B4!
   <bradk> OK. What about images? As is on those too?
   <fantasai> images are no different than other content
   <bradk> OK with me

CSS Filters

   dbaron: we might want a work item in the charter for some sort of a
           filters spec
   fantasai: that would be something with the SVG folks
   fantasai: maybe make them primarily responsible for that?
   * smfr has an action item for public-fx to draft a filters spec
   RESOLVED: add filters spec to charter, as a joint item with SVG
   glazman: how should we name that?
   <bradk> on rectangular images with no alpha channel, you can't see
           the inner shadow. Minor limitation. OK.
   szilles: i have to raise an objection unless it is specified more
            closely than that
   fantasai: the application of SVG filters to CSS
   dbaron: making SVG filters usable for CSS
   szilles: I'm ok with what dbaron said
   (cross talk)
   glazman: what should we name it?
   fantasai: CSS filters?
   <bradk> Extended visual effects?
   glazman: ok
   <fantasai> CSS Filter Effects
   håkon: the idea is to use SVG syntax?
   dbaron: I think we may want a more CSS like syntax for it
   dbaron: we need better notions of CSS layers
   dbaron: SVG has notion of using fill or stroke as input to the filter
   dbaron: we need content, or border, or background as inputs to a filter
   <smfr> i anticipate some "convenience" properties for common filters
   tab: yes we want to do that
   Tab: That was the whole point of Brad's presentation at tpac
   tab: at least for the canned filter effects, we want a convenient
        syntax for it
   <bradk> yep
   bert: url()
   tab: I don't want that
   fantasai: you still have to type the input
   bert: that's what the web is for , URLs
   <smfr> div { filter: blur(10px); }
   tab: I don't want to type URLs!
   <smfr> or div { blur: 10px; }
   <fantasai> no
   <bradk> I agree with tab
   dsinger: let's table this argument
   bert: i object to reinventing the wheel
   (syntax bikeshed)
   glazman: we are not going to discuss this now
   <smfr> gtg
   dsinger: once we have a editor's draft we can then argue
   <sylvaing> i don't object to reinventing bert
   glazman: we can close this topic now

F2F Scheduling

   glazman: next meeting in Lyon in November
   glazman: dbaron proposed to host next meeting after that in Mozilla
            in Mountain View
   glazman: March
   szilles: we also need summer
   glazman: june or august?
   <anne5> is http://software.hixie.ch/utilities/js/live-dom-viewer/saved/596
           a bug in Firefox?
   <anne5> I think it's https://bugzilla.mozilla.org/show_bug.cgi?id=319729
   * anne5 added a comment with the above test
   szilles: tpac will be in oct or nov and not in europe
   dbaron: boston in november is not that bad
   glazman: we still need one between tpac and moz
   jdaggett: proposal, it would be really good to get a set of people in Japan
   <sylvaing> thinks we are due to host and strongly suggests august
   <sylvaing> but definitely prefers Japan :)
   dbaron: march, june or august? i don't know.
   tab: bay area is great in june
   dbaron: maybe we shouldn't sched too much for the weather
   <bradk> +1 for bay area
   <sylvaing> dbaron: weather is important so we can show seattle people
              what a shadow looks like
   <sylvaing> would actually prefer june, early august at the latest.
              just remembered I'm getting married around that time (ahem)
   <bradk> Congrats!
   (office discussions)
   <TabAtkins> woo!
   <dbaron> sounds like things moving towards Mozilla/Mountain View in
            March and Tokyo in June or so...
   <fantasai> Adobe, Opera, Google, and Mozilla will check availability
              for Tokyo in June
   <bradk> Where/when is next tpac?
   <fantasai> boston november 2011?
   <gsnedders> bradk: November, Lyon
   <gsnedders> OR you mean after that?
   <dbaron> fantasai is guessing about Boston November 2011
   <dbaron> but it seems somewhat likely
   <bradk> K, thanx
   <sylvaing> if Mozilla hosts in Tokyo in August, shouldn't someone else
              host in March ?
   (discussion of weather continues)
   <jdaggett> sylvaing: talking about tokyo in june
   <jdaggett> at (mozilla, adobe, google, or opera)
   (holiday family reunion discussions)
   <sylvaing> jdaggett, check. thx.
   (minuter taking a break)
   <fantasai> first week of June, 2nd half, works for me, Bert, and Steve
   <fantasai> glazou, too
   <sylvaing> sylvaing++
   (calendar math discussions continue)
   <dbaron> 2nd half == wed-thu-fri
   <fantasai> WTF first week of June
   <fantasai> 1-3
   <fantasai> I think
   <jdaggett> jdaggett: yeah, june 1-3 sounds good
   <dbaron> dsinger says bad for March 14 or March 21 weeks
   <dbaron> Elika has conflict Feb 26
   <jdaggett> talking about early march at mozilla in mv
   <jdaggett> week of feb 28th/march 7th
   <dbaron> Feb28-Mar1-Mar2 is a M-T-W
   <bradk> Sorry, is the meeting over?
   <gsnedders> bradk: You think they can agree meeting dates that quickly?
   <dbaron> Mar 2-3-4 (W-R-F) or Mar 7-8-9 (M-T-W)
   <glazou> bradk: yes tech discussions over
   <Bert> We're just discussing ftf dates, no more topics for today.
   <bradk> OK. I don't think I have anything to block me for 2011 meeting
           dates at this point, so I will sign out. Bye.
   <dbaron> SXSWi is Mar 11-15
   <dbaron> ok, so tentatively Mar 7-8-9 (M-T-W)
   glazman: that's it for today

Meeting closed.

Received on Wednesday, 1 September 2010 03:11:37 UTC