W3C home > Mailing lists > Public > www-style@w3.org > April 2010

[CSSWG] Minutes and Resolutions Cupertino F2F Wednesday 2010-03-31

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 08 Apr 2010 00:15:05 -0700
Message-ID: <4BBD8279.9020303@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - Discussed integrating CSSOM with other specs: both defining APIs and
     using consistent terminology. Anne actioned to write a list of inconsistent
     and missing terms.

   - Terms "property value" and "component value" suggested to distinguish the
     different uses of "value" in the specs. (Both can be shortened to "value"
     where non-ambiguous, preserving current spec text in most places.)

   - Discussed various ideas for making the CSS Values API more user-friendly

   - Set up a wiki page to track CSSOM numbered constants, to help us avoid
     conflicts in the specs. <http://wiki.csswg.org/spec/cssom-constants>

   - Discussed CSS editor requirements for CSSOM APIs

   - RESOLVED: Alex and Daniel will start a CSS Editing Task Force for discussing
               issues relevant to CSS editors and defining their requirements for
               an object model.


   - Reviewed open issues on CSS3 color so that dbaron can close them.

   - Some discussion on animating gradients

   - RESOLVED: Rename 'image-fit' and 'image-position' to 'object-fit' and
               'object-position' since SVGWG considers the former ill-suited
               to their use.

   - Tab Atkins ran a long discussion on CSS layout, some specific use cases,
     and the relationships between template layout and tables, and between
     flexbox and tables.

   - dbaron proposes calculating available height similar to available width,
     which would allow percentage heights to work even when the parent has
     'auto' height. Since this would be backwards-incompatible, it seems likely
     this will be used for the 'fill' keyword instead.

   - RESOLVED: For CSS2.1 Issue 156, use "Once the font family's weights are
               mapped onto the CSS scale, missing weights are selected as follows:"
               as the introductory sentence, then add bulleted list from

   - env() date values changed to 'local-date', 'local-time', and 'local-date-time'
     since they are formatted according to the system locale

   - 'border-clip' property moved from GCPM to css4-backgrounds


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

   Tab Atkins
   David Baron
   Bert Bos
   Tantek Çelik
   Beth Dakin
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   Håkon Wium Lie
   Chris Lilley
   Peter Linss
   Alex Mogilevsky
   David Singer
   Anne van Kesteren
   Sam Weinig (Apple)
   Steve Zilles

Scribe: TabAtkins


   plinss: First topic this morning is CSSOM.
   plinss: And impact on other specifications.

Integrating CSSOM and other specs

   anne: While editting the spec, I noticed a few problems.
   anne: One is that there's no real data model.
   anne: The CSSOM is supposed to have a represetnation of what the
         stylesheet is like.
   anne: But in the CSS specifications there is no clear mapping from
         the syntax to the data model behind it.
   anne: A clear example is the font-family property.
   anne: I think most impls internally represent them as strings, but
         that's not stated anywhere.
   anne: So when you try to design a value API, you have to state it there.
   fantasai: The font-family syntax I put up said explicitly that Computed
             Value should be strings, so I agree.
   anne: We need Specified Value too. Basically, what you get after parsing.

   anne: Two, there is surprising lack of consistency in the interface names.
   anne: Like, an interface named CSSStyleRule, that maps to a css ruleset,
         but that term isn't really defined in the grammar.
   anne: I'm not sure if we actually want to change the CSS spec, so this
         makes sense, or what?
   anne: What I'm asking is if we want to adjust the terminology so that
         it's consistent between CSS and CSSOM.
   anne: I'm guessing we can't change the interface, so it would be CSS
         that changes in a few points.
   anne: Also, CSS spec refers to a lot of things as just 'values'.
   anne: But in CSSOM, that needs to be something separate, like a 'value
         component', because a property can have multiple of them.
   anne: The CSS spec is kind of loose with those things.
   howcome: I agree, the spec shoudl change there.
   ChrisL: The spec is focused on taking text into CSS, not in reverse. The
           OM spec should define that.
   fantasai: No, I think the spec is ambiguous in a lot of places.
   Bert: There is context where we call many things values, and if we
         introduce multiple terms for these it would be too confusing.
   glazou: I heard the same thing when I introduced the [multiple types of
           selector groupings]
   dbaron: I objected to that at the time because a term was actually being
   anne: There are other specs where there are multiple concepts being
         referred to as the same thing. And that's fine, as long as there's
         a disambiguation at some point.
   Bert: That disambiguation is present in the <> forms.
   fantasai: I recommend 'property value' and 'component value', so they
             both abbreviate as 'value'.
   howcome: Agreed, we shouldn't be changing tons of terms in the spec,
            but the disambiguation is needed.

   ChrisL: Question about CSS color component. Is that used a lot, and is it
           memory constrained?
   anne: We can change it if necessary. Specifics are still mutable.
   <ChrisL> would prefer to see attribute long red; instead of attribute
            short red; - color bit depth is increasing now

   anne: I can work around the lack of terminology, or invent my own, but
         it would be nice if it matched up.
   fantasai: Do you have a list of terms that you need?
   anne: No.
   fantasai: I think the next step is to come up with that list of terms,
             so we can make sure it's defined somewhere.

   anne: The grammar uses the term "statement" to refer to @ rules or
         rulesets, and the CSSOM spec refers to them as "CSSRules".
   fantasai: I think CSSOM should be changed there.
   anne: [describes the terminology, and how it can't be changed at this point]
   <ChrisL> http://en.wikipedia.org/wiki/Deep_Color
   fantasai: I'm not saying change the interface name, but you can say that
             "CSSRule" refers to what CSS calls "statement".
   anne: I tried to do that before, but it didn't make much sense to me.

   TabAtkins: I'd heard you talking before that it would be useful for specs
              to define how they should be reserialized, frex how to turn a
              gradient back into a string?
   anne: Yeah, something in the future is for the CSS specs to be aware of
         the CSSOM in their writing.
   anne: Like when you serialize the margin property, do you do as few values
         as possible, or write it out fully?
   ChrisL: I agree with anne that specs should be aware of the CSSOM and
           write things in respect to that.
   Bert: I think that the CSSOM should refer to CSS, not the other way around.
   anne: There are several CSS specs that include interfaces.
   Bert: Yeah, I think those should be taken out.
   anne: I think it would be acceptable for me to have an ever-growing OM
         spec, but that isn't compatible with how the w3c does recs.
   plinss: I think we agreed that specs going forward would define interfaces.
   fantasai: We agreed that they would define serialization, not that they
             would define interfaces
   plinss: It makes sense for the OM to define interfaces that are common
           across many specs, but we also shouldn't wait for a monolithic
           OM to include all the specialized interfaces that a module might have.
   Bert: it doesn't have to be monolithic, you can publish a separate spec
         for each module's OM
   plinss: We can have two conformance classes, if you support the OM you
           have to support X and Y, if not you just have to support X.
   arronei: It's just a few lines in the conformance section to add the
            conformance requirements.
   fantasai: But we have several specs in CR that don't include an OM section,
             and I don't want to pull them back to add that.
   fantasai: We could create new OM specs just for those.
   dbaron: That's a lot of specs.
   anne: I'm fine with including that stuff in CSSOM.
   fantasai: Half the generic stuff isn't even defined yet, and as for me I
             have *no clue* what to put in for the OM section
   fantasai: If you can give me a template that I fill in to add OM stuff,
             I can do it. But until then, I don't want to have to add them
             to the spec.
   plinss: The person editing a given module may have no clue what the OM
           requires, what's a good idea, and so in that sense it may make
           sense to have a separate OM module for it.

   anne: For value APIs, new values, we do want interfaces.
   Bert: But for new keywords or lengths or numbers, those already exist?
   anne: Yes.
   anne: And for backgrounds, it might be sufficient already since it's a
         comma-separated list.
   anne: For transforms, animations, they all introduce properties with
         slightly more complex values that need new value interfaces.
   plinss: Any new @ rule needs an interface. And depending on how granular
           we get with the API, we may need to extend it for more things.
   anne: And the Images module, it would need to define new interfaces for
         the new things in there.
   plinss: Any conclusions on this?

CSSOM Numbered Constants

   Bert: There was something about numbering, and them having to be unique.
         Is there any way to avoid this?
   anne: The pattern that is used all over most APIs is to use numbered
   anne: For CSSRule we can't change the pattern. For CSSValue I suppose
         we could, but we haven't discussed it yet. I think it makes sense
         to keep it with the familiar way.
   Bert: Does every @ rule need a new number then?
   anne: If it exposed the same information as another @ rule, it can
         reuse a number.
   plinss: @page introduces multiple different @ rules, which would all
           need a number.
   anne: We have @page and friends, @font-face, @media, @import, and
         stylerules, all with different numbers.
   anne: So far new @ rules probably want a new number.
   anne: Like all the @margin rules might share a single number.
   Bert: Numbers need coordination, which I think we should try to avoid
         if possible.
   anne: I think we should just try to coordinate.
   anne: We managed to do it pretty well for DOM Exceptions.
   Bert: Who do we have to coordinate with. Just here, or do we have to
         coordinate with SVG?
   anne: Officially SVG has to coordinate with us, but I've reserved
         some space for [something SVG-specific].
   [talk about different impls stomping on numbers]
   <fantasai> make the constant point to a UUID? :)
   ChrisL: We need an easily referencable page where we can refer to this
           and stop conflicts.
   [discussion on using a wiki for coordination]
   anne: There is a way with WebIDL that you can extend an interface.
   Bert: You can reference a wiki as an informative reference, but not
         a normative one.
   anne: Yeah, sure, it can be informative. That's fine.
   fantasai: So these numbers are all named constants, and people are
             supposed to use the names?
   anne: Theoretically.
   fantasai: Can we have the named constant return something other than
             a number?
   anne: No, the type is a short.
   anne: Same thing is done with, say, Nodes, but that doesn't chang
         very often. CSS adds new things somewhat more often.
   plinss: If you're implemeneting something early, like Paged Media in
           webkit, should prefixed versions use the same final number?
   anne: No, it says right now that the CSSWG reserves the first 1000 values.
   plinss: So proprietary versions should use a number above 1000.
   ChrisL: Will implementations switch from >1000 to <1000 when they get
   anne: When they drop the prefix should be fine.
   plinss: Should we try to reserve blocks for individual browsers?
   fantasai: Authors should just use the named constants.
   smfr: Should the named constants be prefixed?
   anne: Good question. If you don't prefix, there's a chance that code
         would still work when it moved to standardization. But if we
         changed anything, then it could break.
   anne: Ideally we'd iterate fast enough that we don't run into that situation.
   anne: If people want to write their thoughts to the list, it would be fine.
   ACTION: anne to set up wiki page to list CSSOM constants for coordination
   <fantasai> anne, http://wiki.csswg.org/spec/cssom-constants

   plinss: Did we come up with a decision for how to do OM sections for new
   anne: I think for specs in WD, it would make sense to have them in the
         spec. But perhaps we should defer that a little and discuss the
         value APIs first.

CSSOM Values APIs Part I

   anne: So currently for the value apis you get a CSSStyleDeclaration object,
         with a long list of attributes that represent CSS properties.
   anne: And they all return a string.
   <smfr> http://dev.w3.org/csswg/cssom/#the-cssstyledeclaration-interface
   anne: The initial idea we had was that instead of a string it would
         return something special, that would act like a string but would
         allow extensions.
   anne: I brought it up on public-script-coord, where ecmascript guys
         hang out, but they didn't think it was a good idea.
   anne: [some examples of breakage]
   anne: Based on that we have a new idea. The CSSStyleDeclaration object
         would have a new property called values, which would return a
         CSSStyleVales object.
   anne: It would act like StyleDeclaration, but when you access a property,
         it would return a CSSValue object rather than a string.
   anne: The object would have a cssText attribute that lets you set a string
         or get a serialization, which is equivalent to the existing API.
   anne: So then the question is how to define the new value APIs on top of that.
   anne: I think we want interfaces for the components.
   anne: So an interface for %, for lengths, for color values
   anne: And if you have a width property, that supports both lengths and %,
         the object returned would implement both.
   <smfr> http://dev.w3.org/csswg/cssom/#the-cssvalue-interface
   anne: It would have an .px and .em accessor, but also a percentage accessor
         so you could set and get %.
   anne: So how far do we want to go? Each and every property, or start out
         with a limited subset?
   anne: And do we need a "type" like CSSRule so you can figure out what kind
         of value was set?
   anne: Like, ComponentValue would return a type of lengthEm, lengthPx, etc.
         Would that be a short, like the other types? Or a string that could
         be interned, which could be more extensible.
   anne: If we did numbers, then if we start filling in spots, say if we
         added a new length, it could be very separated from the other lengths.
         px could be 12, and rem could be 100.
   plinss: As long as people use names, the numbers wouldn't matter much anyway.
   plinss: We could also reserve blocks.
   szilles: So what's the downside on strings?
   plinss: Performance.
   anne: If they're interned, it would just be pointer comparisons.
   plinss: I'm concerned more with author script stuff. Will I be doing a
           thousand string comparisons, or a thousand short comparisons?
   smfr: Potentially, we could have them do atomic string comparisons.
   <fantasai> You might also want to answer things like "is this a length
              (any kind)" or "is this a percentage"
   anne: Can we define constants that are strings?
   Sam Weinig: Nothing theoretically wrong with it. The strings are essentially
   anne: How do we, at the object level, distinguish between value components
         and things that are separated lists of value components.
   anne: Like, background-position takes two values.
   anne: So how do we represent that?
   plinss: I think it should return a backgroundPosition object that has two
   glazou: We could return an array with the components in the order they appear.
   plinss: Or an object with queryable values, so it's more extensible.
   anne: Also, do we want a special interface for shorthands? Like margin
         should we implement a margin property or only margin-left,
         margin-right, etc?
   dbaron: Also there are some non-shorthand values that are rather complex,
           like shadows or border-image.
   plinss: We could pretend they are shorthands and expose them as such in
           the object model.
   anne: But then we're stuck if a property later becomes a shorthand.
   fantasai: Like we're going to do with whitespace.
   smfr: I think the hash-table approach would work for shorthands.
   fantasai: So, for the 'margin' shorthand you'd be able to look up the
             'margin-left' value and 'margin-right' value?
   <dbaron> A bunch of the complex-valued properties are arbitrary-length
            lists, which are hard to represent as shorthands.
   glazou: If possible, harmonize things across properties, so "x" is the
           same for all the values.
   sam: In that case you wouldn't have named components, but rather numbered
   fantasai: You could have named components that are lists
   plinss: We've already had things that take a single value and turned them
           into lists of that value.
   anne: A simple example would be background-image, which would return a
         css url, but also have a way of getting a list of css urls.
   dbaron: I think the single-value thing should only return the single
           value if there *is* a single value, and otherwise do whatever
           happens when it is being a wrong type.
   glazou: Recursively nested values.
   <dbaron> What's interesting with url() values is often an absolute URL
            rather than a relative URL relative to the style sheet.
   glazou: In the case of color, rgb returns a single color value, which
           also has .r, .g, .b.
   glazou: etc.
   glazou: Editors will *massively* use CSSOM if it is easier to use, but
           not if they have to reparse/rebuild values into a useful form
           every time.
   anne: I think you want interfaces for this.

CSSOM for Editors

   glazou: Another thing I want to see in the CSSOM, some things just for
   glazou: Like not just the reserialized text, but the original parsed text.
   glazou: Like if the @style attribute has something wrong, browsers
           currently throw it away and it's hard to get at that.
   glazou: Browsers don't need that, so they can just return null or whatever,
           but editors are allowed to return the full thing.
   sam: Is that confusing for authors?
   anne: If it's not for browsers, do we need it in the spec?
   glazou: Yes, if you have multiple editors you want interop.
   smfr: So what if someone wants to write a javascript editor tool in a
         normal browser?
   TabAtkins: Like FireBug would love this.
   smfr: Isn't this what UnknownRule is for?
   dbaron: UnknownRule was designed by someone who doesn't understand CSS
   plinss: We could just tell browsers to *not* throw away these things.
   sam: For Firebug and Web Inspector we use internal hooks, and don't
        need the specced thing.
   arronei: What if I'm a brand new editor for HTML and CSS? This is where
            having a spec would be great.
   sam: The issue is that it would slow down browsers. We can either decide
        that we have it anyway, or not.
   smfr: We could have a runtime switch controlled by the OM. It's weird,
         but shrug.
   * ChrisL bijectively
   [discussion about editors and browsers throwing things away]
   glazou: A live editing tool for HTML and CSS right now is impossible
           because of this limitation.
   <fantasai> I don't think UnknownRule or UnknownAnything is necessarily
              the way to go. You should have a unified API insofar as
              possible. You can have MalformedRule or something for things
              that can't be parsed...
   <fantasai> But if it's clearly propertyname : valueIcan'tUnderstand, you
              should get an api that works the same as for color: blue;
   <fantasai> and returns the propertyname and the string representation
              of the value
   anne: We've had this discussion before. I thinkwe might want some editing
         features already, and we might want to move those upward.
   anne: But I think we need a more concrete proposal for how to modify the
         OM for editors.
   glazou: concrete example: firebug, dragonfly, etc, from a given element,
           you can climb up the cascade to find which element triggered
           the current rule. But it's not standard!
   glazou: We all use proprietary interfaces to do it.
   anne: That's something we can definitely standardize.
   anne: For changing the parsing engine we need more detailed proposals.

   dbaron: CSS is harder to get right because you've got comments anywhere.
   glazou: My own impl preserves comments between rules and between
           declarations. But that's a big bloat for browsers.
   plinss: in the early days of gecko I made something that preserved all
           the information, and if it found a comment somewhere odd, it
           would shove it forward to the next 'normal' point for comments.
   glazou: That's not perfect, but yeah it works.
   glazou: I perfectly understand the browser's concerns wrt bloat and footprint.
   glazou: But adding nothing at all shuts the door to a whole class of
           live applications on the web that are everywhere these days.
   glazou: Wikis are everywhere, styles are everywhere, and we still can't
           edit styles.
   anne: We can largely edit it. Not every property, but most of them.
   anne: I think most editors let you edit the text file.
   ChrisL: Because the OM isn't up to the task yet.
   howcome: That's what the spec is trying to fix, right?
   anne: For WYSIWYG you don't need comments, so I see some conflicts.
   howcome: I think Anne is trying to get this done, and you're being
            aggressive to him.
   glazou: I'm not aggressive, I love what you've done, I just want to see more.
   smfr: You should both be able to edit the text directly, and move to
         doing sliders and such, and go back. We need that for our editor.
   plinss: The Web has a legacy of documents being editted by hand, and we
           can't just throw that away into a non-hand-editable spec as
           soon as machines touch it.
   sam: I think that Anne's work doesn't impede any of this.
   glazou: I think that when OM was first created, editors weren't in
           anyone's mind.
   plinss: Gecko actually got built to be an editor. The fact that it
           turned into a browser is happenstance.
   plinss: While we were designing that stuff, we saw the convergence
           of editors and browsers as the web develops.
   plinss: We eventually realized that the only difference between gecko
           being a browser and being an editor was a stylesheet.
   anne: We just need to find what the cost for benefit is. If browsers
         already preserve comments, we can look into that, but we can't
         put comments everywhere.
   anne: And what about whitespace?
   glazou: What's important is maintaining what was entered. Like for
           border-radius, you can't just have everything but the
           -moz-border-radius thrown away just because that's the only
           one that was recognized.
   anne: If someone can define what sort of string would be produced,
         and browsers are okay with the footprint, we'd be okay.
   fantasai: I think you would start parsing, and get the property
             name as an ident.
   plinss: ident, colon, stuff, semicolon.
   sam: So basically we'd have something more than unknown rules, for
       unknown declarations too, and a browser mode that would change that.
   fantasai: For all rules too.

   alexmog: Let's have a CSS editing requirement TF and come up with a
            list of requirements for object model, for editors, and
            other features, so we can figure out what the goals we're
            trying to achieve are.
   alexmog: Right now we're designing a partial object model. We can
            possible change the OM into something that does what we
            need, or something completely different for editors.
   alexmog: [he talks to VS people twice a year about this, various requests]
   RESOLVED: Alex and Daniel will start a CSS Editing TF.

   anne: I think if you want it to end up in browsers you want it to
         reconcile with the OM.
   glazou: Yes.
   alexmog: I'm not quite convinced if a high-powered editor needs to
            be built on the object model.
   alexmog: Like if there are only a small number of companies building
            major editors, they may not need a full OM in favor of just
            a more editing-friendly interface.
   plinss: The same thing happened with HTML. First browsers didn't
           remember anything about the HTML, and the object model got
           thrown away as it was parsed. But we gradually kept around
           more of the model.
   plinss: So we need to extend this over CSS.
   plinss: We didn't build the DOM to build an editor, it just happens
           to also be useful for this.
   glazou: We know there are some things that we always can't do, like
           preserving comments everywhere.
   <bradk> It would be nice if the various developer tools (FireBug, etc.)
           preserved (and flagged somehow) properties and values that had
           typos or spelling mistakes, so that they can be edited and
           fix in-browser.

<dbaron> glazou, http://dbaron.org/css/timing-function-graphs

CSSOM Values API Part II

   anne: We need to have the hash-table concept for values that are
         space-separated, and a list concept for values that are
         comma separated?
   anne: for margin, you'd return a hashtable-like interface with each property
   TabAtkins: We just need to make sure that properties that later
              turn into shorthands still work by themselves.
   sam: My suggestion to anne was to take some of the more complex
        examples of syntax, break it down into concrete proposals,
        and put that on the list.
   fantasai: I suggest border image.
   glazou: Font stuff too.
   sam: Whatever is *as hard* for anne as possible.
   fantasai: shadows and the content property.
   ACTION: anne to produce concrete examples of complex properties and
           put it on the list

   smfr: We also need to define if every property has a canonical form.
         If someone specifies 'ease' in a timing function, do they get
         'ease' back or a bezier function?
   plinss: As much as possible we should return what the author specified.
   anne: We could have a .keyword value that would return a keyword if
         the value corresponds to a keyword.
   glazou: Same with color - if the author says "red", do we do 'red',
           '#f00', rgba(255,0,0,1), or what?
   anne: Browsers try to store as little as possible right now.
   plinss: For a browser, no matter what gets specified it'll be stored
           as a [r,g,b] or whatnot, and I'd want back what the author
           actually said sometimes if possible.
   anne: We might have a bit that says if the color was originally a
         keyword or whatnot.
   anne: Currently there are a number of normalization rules for various
   plinss: I'm concerned that some of them go too far.
   plinss: If you have multiple ways to pull a value back out of the OM,
           that's fine, but when serialized to text it should be as close
           to what the author said as possible. We can change "Red" to
           "red", don't need bit-for-bit, but the spirit should be the same.
   smfr: One problem I have with gradients is that there's no canonicalization.
   TabAtkins: Agreed, I need to add that.

CSS3 Color Issues

   <dbaron> http://wiki.csswg.org/spec/css3-color
   <smfr> editor's draft: http://dev.w3.org/csswg/css3-color/
   dbaron: Currently the editors draft addresses most of these issues,
           but I haven't yet replied to the emails with these comments.

   dbaron: First is issue 5.
   dbaron: At first I thought it was someone who didn't understand the
           spec, but I realize now that there isn't a good description
           of what rgba means.
   ChrisL: And I think it should explain how it interacts with opacity
           (multiplied together).

   dbaron: A repeated comment we got was the gamma correction section
           being out of date; I think I've addressed that.
   ChrisL: Yeah, looks like it.
   ChrisL: Beth will send me an email that gamma has changed between
           Leopard and Snow Leopard.

   dbaron: The wording of the spec in general isn't great about what
           conformance requirements are, so there are some issues where
            I think I can improve that relatively easily.
   dbaron: Frex, it says "here is how to convert hsl to rgb", but it
           doesn't say you *have* to do that.
   ChrisL: yeah, that should be normative.
   ChrisL: Also there was an issue about color spaces and color width
           and such. All colors should be sRGB, and 0-255.

   dbaron: Issue 13
   dbaron: Someone suggested we remove the statement about clipping
           values outside the device gamut, which makes me wonder what
           to replace it with.
   ChrisL: I don't think they understood the issue. Do we have a
           conformance requirement to display colors you can't
           physically display?
   dbaron: I think that we might not quite want to clip, but might do
           some special mapping near the edge.
   ChrisL: [example with differing gamuts]
   ChrisL: After doing gamut mapping, if I still end up with values
           outside the displayable colors, it must be clipped.
   dsinger: Are you modifying what you remember the user asked for,
            or what you are trying to display?
   ChrisL: If it's implying that what is specified goes 1-1 with
           device gamut, that needs to be changed.
   dbaron: Right, that's why I want to change "clipped" to "clipped
           or mapped".
   ChrisL: "clipped or mapped" isn't fine.
   ChrisL: You need to say "values outside source gamut should be
           mapped to device gamut, values outside device gamut
           must be clipped".
   dbaron: What's the source gamut?
   ChrisL: The color space you're coming from, sRGB.
   dbaron: CSS allows values outside of sRGB.
   ChrisL: Yes, that's fine. If you have a printer that can do blues
           outside of sRGB, that's fine, CSS lets you express that.
   ChrisL: But if you're showing on a screen, you can clip to the
           device's gamut.
   dbaron: How is the source gamut related to things here?
   ChrisL: I should have flagged 'device gamut' more. Once you've
           mapped to the device gamut, *then* you need to clip
           anything outside of it.
   Bert: The device clips them for you, right?
   ChrisL: Typically the driver clips them for you.
   ChrisL: You need to introduce the term source gamut and device
           gamut, and use them separately.
   dbaron: What is the source gamut?
   ChrisL: In here, sRGB, or any other color space if we allow more later.
   dbaron: But we allow things outside of sRGB.
   ChrisL: Right, nobody is talking about clipping source gamut.
   ChrisL: I can take an action to give a better description here.
   szilles: [suggestion for communicating this without using the term gamut]
   ACTION: clilley to rewrite the paragraph in CSS color concerning
           gamuts and clipping

   <smfr> http://wiki.csswg.org/spec/css3-color#issue-18
   <smfr> http://lists.w3.org/Archives/Public/www-style/2008Sep/0006.html
   dbaron: It's one of the later messages in the thread.
   ChrisL: Marbux is a troll.
   glazou: We still need to respond to trolls.
   glazou: Talked to AC people, they said it was no problem.
   glazou: So we have an answer. It's member-only, but it's not a
           technical issue, only a legal one. It probably deserves
           a member-only answer.
   ChrisL: So resolution is no change?
   szilles: The "be" change should happen, though, right?
   dbaron: That's editorial, yeah.
   ChrisL: So we can say "We agree with the editorial comments from
           the XSL-FO working group". It makes it clear who we're
           agreeing with.

   dbaron: There's a note at the bottom of the system colors section
           that I think is wrong.
   dbaron: It says the computed value of a system color is the keyword itself.
   dbaron: First it's weird that a normative requirement is a note,
           and I think it's wrong anyway.
   dbaron: So system colors should compute to a color.
   ChrisL: Sounds good.

   ChrisL: I've seen Issue 20 come up in hypertext coordination group
           before, and so we need to say what we mean by 'deprecated'.
   dbaron: We mean that impls should still implement it, but new
           content shouldn't use it.

   ChrisL: Issue 27, we should discuss it.
   ChrisL: I assume it's because we can get it out this decade?
   dbaron: It doesn't have real dependencies; it can go to 2.1 just fine.
   <dbaron> Sounds like people are all happy with depending on CSS 2.1

Animating Gradients Part I

   plinss: Next topic is animation of gradients.
   smfr: I think this came up because the Transitions spec said
         gradients were animatable.
   smfr: I think this is a mistake because gradients aren't a property,
         but rather a type of image, and we don't know how to transition
         images yet.
   smfr: Also I think this might be something for the public-fx group
         to input into as well.
   ChrisL: Could you send a mail to the list about that?
   ChrisL: [talks about how animating gradients in SVG is easy]
   TabAtkins: I've got a goal with shepazu to unify some underlying
              concepts in CSS and SVG, to make those things easier.

image-fit and image-position Part I

   plinss: Next topic is image-fit and image-position
   fantasai: We can't do much, since that was supposed to be for SVG coord.
   fantasai: But one thing we can talk about is naming. SVG wanted new
             names for things.
   fantasai: We might be able to discuss that.
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Sep/0304.html
   <anne> btw, http://blog.mozilla.com/security/2010/03/31/plugging-the-css-history-leak/
   howcome: image-* isn't perfect for video either
   fantasai: fit-aspect-ratio says that you're fitting the aspect ratio
             to the box.
   fantasai: As far as the most useful information you can stuff into
             the property, that's fine.
   ChrisL: So fit-aspect-ratio and fit-position are good?
   howcome: No. What if you put it on a <p>?
   fantasai: No aspect ratio, so it doesn't apply
   howcome: Are there other suggestions?
   Bert: Without something pointing to images or replaced content, this
         sounds too general.
   dbaron: What's the list of values for this?
   TabAtkins: For aspect ratio: fill, cover, and contain. For position,
              a bg-position.
   howcome: Why isn't image good enough for SVG?
   dbaron: If I hear "aspect-ratio", I expect something that looks like a ratio.
   fantasai: Maybe aspect-ratio-fit, but then it's weird to combine
             them into a shorthand.
   smfr: content-fit, or just fit?
   Bert: We had that.
   TabAtkins: We had content-fit, said it was too general, and changed
              it to image-fit.
   <smfr> http://dev.w3.org/csswg/css3-page/#img-fit
   TabAtkins: This specifically says "replaced elements", which isn't
              great for SVG.
   fantasai: When SVG imports it, they can tweak applicability wording
             for their own purposes.
   fantasai: In CSS, all values have no effect on non-replaced content.
   Bert: content-* has another advantage, in that it refers back to the
         content property, which can produce a replaced element.
   * fantasai thinks that nobody will find 'fit-content' when they're
     looking for it if it has neither aspect-ratio nor image in its name
   <Bert> 'content-fit' not 'fit-content'
   [naming discussions]
   <bradk> 'scale-how' and 'position-how'
   <Bert> (I still prefer 'image-fit', though)
   <fantasai> 'aspect-ratio-fit'
   <fantasai> 'fit-aspect-ratio'
   <fantasai> 'content-fit'
   <fantasai> 'fit-content'
   <fantasai> 'fit-scaling'
   <fantasai> 'scaling-fit'
   <dsinger> fitting?
   <dsinger> 'replaced-element-fit-behavior'?
   <bradk> fitting:have(1)
   <fantasai> q+ for motion to switch topics until Molly can join the discussion

<br type=lunch>
<sylvaing> image-spread

<mollydotcom> Hi all - guessing you're off for lunch?
<TabAtkins> just getting back, actually
<mjs> did you guys solve all problems with CSS yet?
<anne> we added some problems

Animating Gradients Part II

   [continuing discussion about combining animations and gradients]
   [specifically, maybe attaching animations to transitions, rather
    than states?]
   [dean talking about animations with implicit start and end, like
    transitions do]
   [if, say, you animate left when you transition a color, what's
    the final value of left?]
   <Bert> (If 'transition-properties' has a value foo, then foo
          animates, even if the start and end values are the same.)
   [discussion about new selectors to address the hover/unhover animations]
   [something more analogous to mouseenter/mouseleave, rather than
    mouseover like :hover is]
   [or something that explicitly captures a state transition, like
   [combinatorial number of state transitions]
   [event-based CSS property]
   [back to keyframes for transitions?]
   <anne> you could have something like :leave(:hover) or :leave(.test)
          for when something stops applying...
   <anne> but keyframes for transitions is prolly an easier solution

image-fit and image-position Part II

   plinss: Back to naming of image-fit and image-position,
     sincy mollydotcom is here.
   <glazou> mollydotcom, we need your expertise finding names...
   <mollydotcom> I'm here to talk about that
   smfr: dsinger had a suggestion that he put into irc earlier
   smfr: viewing-scale : letterbox | crop | fill; viewing-position : ...
   <mollydotcom> do you want me to call in or shall I just type?
                 Both hurt, typing less so as my throat is so swollen.
   <glazou> mollydotcom: see conf call data just above
   <fantasai> how about we call in, and you type?
   <fantasai> that way you can hear everything
   <mollydotcom> ok, I'll call in and say hi and then type
   <mollydotcom> thanks
   <fantasai> :)
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Sep/0304.html
   mollydotcom: Elika has caught me up a little bit on the issue.
   mollydotcom: We've been talking about this for a long time.
   mollydotcom: If someone can pinpoint the terminology that we're
                struggling with, I can help out.
   fantasai: We got a message from SVGWG, prompting the discussion.
   mollydotcom: Main concern with image-fit and content-fit is that
                we're really not talking about images or content.
   mollydotcom: It *may* be an image, but it's not traditionally
                what we call 'content'.
   mollydotcom: I suggest, for semantic rationale, 'object-fit'.
   howcome: Steve suggested that over lunch as well. I think it
            covers the things we're talking about here.
   mollydotcom: Right, whether it's a video or some SVG or an image
                or an applet, we can call all those 'object'.
   <mjs> does 'object-fit' really add any meaning to 'fit'?
   <mjs> pretty much anything can be arguably an 'object'
   mollydotcom: I have a problem from an educational perspective
                with using 'image'.
   mollydotcom: I think 'object' does add meaning to 'fit'.
   mollydotcom: I don't think it's true that *anything* can be an
                object. In the markup world, that always refers
                to a replaced element or similar.
   fantasai: Agreed.
   <mjs> in HTML there is specifically the <object> element, and
         people would think the property is referring to that
   smfr: That could also bring up the reference to <object>, which
         would suggest an exclusion of <video> and similar.
   mollydotcom: Yeah, that's possible confusion.
   fantasai: I don't think anyone thinks of a paragraph as an object
   <bradk> object has another meaning in JavaScript too.
   <mjs> as a browser implementor, I certainly think of a paragraph
         as an object
   <mjs> HTMLParagraphElement to be specific
   < TabAtkins>As an author, do you think of it that way?
   <mjs> no idea if authors think of it that way; I would imagine
         authors would do a lot of scripting would think of every
         element as an object
   mollydotcom: To designers, 'image-fit' would say to them that
                we can't put a java applet in there.
   mollydotcom: They come at us from a different perspective.
   <mjs> if the intent is to capture all replaced elements, then
         maybe it should be replaced-fit
   smfr: What's the objection to content-fit?
   mollydotcom: Too broad.
   <bradk> sometimes, when I'm dealing with an element in JS
   <TabAtkins> maciej, this will be more than just replaced content
               when SVG imports the property.
   mollydotcom: And for content authors, content refers to the text
                content of the document
   mollydotcom: It seems to me that 'object' is a happier medium.
   <mjs> TabAtkins, what does SVG intend to apply it to? everything?
   <fantasai> object-fit: fill | contain | cover
   <fantasai> object-position: <bg-pos>
   <fantasai> ?
   mollydotcom: To me it looks good, and I think I can have that
                make sense to people
   mollydotcom: I think it's much harder to convey image-*
   howcome: I can live with image-* too, but this is better
   <mjs> I really doubt that "object" adequately distinguishes
         the set of SVG, CSS and HTML constructs it applies to,
         from the set of things it doesn't apply to
   <TabAtkins> maciej, it seems that there *is* no single word that
               does it. Everything sucks somehow.
   * anne doesn't really like object either
   <mjs> TabAtkins, why not just name the property "fit"? does it
         need a noun?
   mollydotcom: We were also talking about scaling
   howcome: I think 'fit' is just too generic.
   <Bert> (We had 'fit' at one point, and decided to change it.)
   fantasai: It seems like it could be a shorthand for fit-position
             and something else.
   mollydotcom: Let's throw it in front of the SVGWG and see what
                they have to say.
   * TabAtkins Next public-fx telcon!
   mollydotcom: We talked about fit-scaling
   <bradk> I still prefer 'scaling-fit'
   <mjs> random proposal: fit-rule: fill | contain | cover, fit as
         a shorthand for fit-rule and fit-position
   mollydotcom: Problem with me is the active word of scaling. It's
                not quite actively scaling.
   mollydotcom: fit-scale, alone, makes sense to designers and similar people.
   mollydotcom: if I say you ahve to scale this particular object,
                that makes more sense to me than saying 'fit-scaling'.
   mollydotcom: In PS and you want to keep the aspect ratio, you just
                click "keep aspect ratio" and just change one value,
                or do it in %s.
   mollydotcom: And that's a very familiar paradigm.
   mollydotcom: So I think the word 'scale' is better, but there's
                vaguery in all of this.
   mollydotcom: We just have to pick the one that is closest and most
                understandable to the most people.
   <fantasai> fit-scale: fill | cover | contain
   <fantasai> fit-position: <bg-pos>
   howcome: So should we just list the alternatives?
   <fantasai> could append <percentage> to fit-scale
   <bradk> On a fit-scale of 1-10, I'm about a 5 maybe.
   <fantasai> 100% would replace none
   <fantasai> fit-scale: fill | cover | contain | <percentage>
   mollydotcom: just giving one would preserve aspect ratio
   mollydotcom: fit-scale: 100% would be the image its actual size
   mollydotcom: fit-scale: 50% scales it down by 1/2
   mollydotcom: Could allow 2 values would allow different scaling for different dimensions

Scribe: fantasai

   howcome writes on the board
   <TabAtkins> howcome: Are these the two proposals we have?
   and either of last two with 'fit' in the front
   howcome adds numbers
   1. fit-scale / fit-position
   2. object-fit / object-position
   3. image-fit / image-position
   4. aspect-ratio-fit (or fit-aspect-ratio) / fit-position
   <mollydotcom> 2 from me
   smfr: prefer 3, but 2 is ok
   anne: same
   steve: 1 or 2, not 3
   beth: 2, fallback to 3 if it has to
   sylvain: 3, then 2
   alex: 3, then 2
   alex: for the same reason I prefer mouse over pointer
   bert: 2, 3
   arron: 2, then 3
   fantasai: 1, then 2
   dbaron: 2 then 3
   tantek: abstain
   brad: 2 then 1
   tab: 1 then 2
   chris: 1 then 2
   daniel: 2 then 1
   peter: 1 then 2
   dsinger: 1 then 2
   howcome: 2 then 3
   dbaron: 2 was first or second choice from everybody
   fantasai: my one concern with 1 is that if you want to add percentage
             scaling, it doesn't work with the object-fit name
   anne points out that if you made a shorthand with these, the shorthand
        would be called object
   <mollydotcom> Anne: you do make a good point
   <mollydotcom> no shorthand should be called object IMO
   <mollydotcom> is there going to be a real need to do that?
   smfr: object-fit-scale, object-fit-position
   smfr: Could combine them and have object-fit-scale and object-fit-position
   <mollydotcom> bye folks!
   fantasai: smfr's suggestion would address the shorthand and make more sense
             with percentages
   TabAtkins: percentages would make a shorthand impossible to parse
   RESOLVED: use object-fit and object-position for the properties

Advanced Layout Modules

   TabAtkins: So, this is going to be less direct suggestions and more
              my plan of action in the future about what to do
   TabAtkins: I'm a Google employee now, and will soon be chrome liaison
   TabAtkins: I want to take the layout drafts and turn them into something
              we wnat to implement and use soon
   TabAtkins: Specifically, Template, Flex, Grid, and a few others maybe
   TabAtkins: I've been thinking for a while what the underlying abstractions
              are in the different layout drafts
   TabAtkins: and also in the different layout modesl I as an author want to do
   TabAtkins: I would like to combine into one model, but don't think I can
              quite do that
   alexmog: Why do you want to do this?
   TabAtkins: Because I as an author want to use them. Because laying out
              in CSS sucks
   alexmog: But you also want one or more browsers to implement
   TabAtkins: I'd also hope to implement some of this myself
   TabAtkins: So, the first model that layout things will be built on is
              table layout
   TabAtkins: turns out table layout is super useful for layouts I've done,
              for doing things I didn't expect before I started playing
              with it
   TabAtkins: Table layout by itself is good, I like the way it lays out
              as a grid
   TabAtkins: the problem is that it restricts your site markup: you need
              to put in containers and order things so that it lays out
   TabAtkins: which can be bad for accessibility
   TabAtkins: Template layout fixes this
   TabAtkins: Once you look into it, it looks just like magic on top of
              table layout
   TabAtkins: So I want to take Template Layout, slightly change it so
              that it /is/ magic on top of table layout
   TabAtkins: That would basically entail setting up the properties so
              set up a table grid out of pseudo eleents
   TabAtkins: and hopefully discussing how content is flowed into the
              pseudo elements
   TabAtkins: hopefully not a significant change in the draft, just conceptual

   TabAtkins: Another thing to add would be another table layout model
              that's sane
   TabAtkins: fixed table layout is sane
   dbaron: no it's not, it's just nobody uses it so nobody knows how messed
           up it is
   alexmog: Even if I don't understand table layout, I can ...?
   dbaron: Another problem with table layout is that putting large things
           into small cells often doesn't do what you want
   dbaron: eg. have one thing wider than viewport
   dbaron: makes the whole table wider than the viewport
   TabAtkins: might be an artifact of auto layout right now
   TabAtkins: Could consider putting out a new table layout model along
              with the mathching template model
   TabAtkins: ...
   dbaron: I removed support for * widths from Gecko because the implementation
           didn't do much
   dbaron: And the HTML4 description of * widths said do what browsers do for
           percentage widths, and the spec for percentage widths said something
   alexmog: WPF does use table layout internally, and it implements * widths
   alexmog: The advantage is that you can put content into any slot into the
   Bert: We could add a third algorithm to table-layout property
   TabAtkins: Building off of table then lets you use auto or fixed layout
              if that happens to be what you want
   Bert: That new algorithm would also allow the flex property in that case
   Brad: Would you bring that into the table display types, too?
   TabAtkins: Yes, if we add it to table-layout
   TabAtkins: the only magic in Template would be to create pseudo elements
              that represent table parts and putting the content in there
   TabAtkins: I'm going to start working on the drafts for these
   TabAtkins: Just wanted to give everyone a heads up

   howcome: You have an implementation as template layout, right?
   Bert: Yes, 3 impls. One uses same syntax as the draft
   <TabAtkins> from alexis deveria
   Bert: The other impls are the ones from Cesar, which uses an older syntax
   Bert: And there's an impl from Andrew F. which uses another variant syntax
   Bert: I like the idea
   howcome: We need something like this, we haven't talked about this for years
   howcome: what about multicol?
   TabAtkins: interact the same way as multicol and tables do now
   alexmog: If you are creating a new kind of a grid, that grid could
            supercede grid positioning
   alexmog: you could use that grid to position floats and have them
            interact with other content
   Bert: My template draft has that, the grid is defined by the template grid
   howcome confirms that grid units are defined in various drafts
   Tantek: what's the general class of use cases that you're going for?
   TabAtkins: Overall site layout
   TabAtkins: I want to make sure that either this directly or this plus
              other stuff is also useful for applications
   TabAtkins: e.g. replace Gmail's hacky stuff
   Tantek: Traditionally, grid-based layouts are really useful for
           application UI
   <anne> did he say he's going to base this on top of table layout?
   <anne> ... also, does that mean someone is going to define table layout first?
   <fantasai> yes
   <fantasai> no clue, probably not
   <glazou> http://glazman.org/howcome-cupertino/
   <anne> ... seems somewhat important to define those primitives if we
          are going to build on top of it
   <anne> ... we always have long discussions on anything table related
          and without a clear overall picture of how that works it's
          just going to get worse

   Tantek: There are a whole class of applications that are doing
           ridiculous backflips to do UI
   Tantek: Having a model that solves those use cases could cause a
           renaissance of web applications
   TabAtkins: If we can come up with necessary flexibility with grid
              then building them together would be great .. (?)
   Tantek: Consider the use cases together, and consider also the implementors
   alexmog: I'm not against unifying the grid
   alexmog: but I don't want to have super-complicated interactions
            across multiple models
   dbaron: I don't think gmail is that gridlike
   dbaron: The layouts tend to be more about taking one piece of UI and
           pushing it against the edge of the space, and then having the
           rest of the area taken up by the rest of the app
   dbaron: You have menus and toolbars and sidebars
   dbaron: In all these cases you're taking the rectangle
   dbaron: taking up one part of it with a UI element, and then filling
           the remaining space
   Tantek: Check out iPhone apps, they have very different UI models
   howcome: We haven't really been able to exploit our table model
            because it hasn't been widely implemented
   howcome looks pointedly at Microsoft
   discussion of WebKit-specific apps and table layout
   Tantek: Interface builders have lots of interesting ways of laying
           out UI elements. It makes sense
   Tantek: snap-to-grid
   Tantek: pin one object to anther object
   Tantek: just spend 15 min with interface-builder
   howcome: Do we consider apps to be the driving force or documents?
   fantasai: Both. We need to handle both.

   Tab talks about grids defined by templates and tables and grids
       defined by content
   alexmog: The grid I imagine is independent of content. You either
            place stuff on the gridlines, or snap to them
   alexmog: The only thing you need to add is size to fit
   alexmog: perhaps horizontal lines should fit to content
   alexmog: that switches grid from trivial to complicated
   Tantek: grids aren't just for UIs either
   Tantek: Things like baseline-alignment across the page is super-hard
           to do today
   Tantek: Grid would presumably solve that
   TabAtkins: You could set up a grid with those line
   TabAtkins: and then with some other mechanism tell text to line up to that
   TabAtkins: You would need separate grids
   TabAtkins: Whether layout grid + baseline grid is sufficient or we
              need author-named grids, not sure
   fantasai thinks we should have named grids

   Bert: Anne asked on IRC, so do you have to write the table module first
        if you are going to do this?
   Anne: What does 'width' mean, what does 'height' mean
   TabAtkins: Don't have to define that, can just say "do what you do currently"
   TabAtkins: and build a new sane table model
   alexmog would like a sane table model
   Anne: I think we might get a bid of redundancy because only a few
         people know what the current one covers and what algorithms
         are defined that we might want to reuse

   Steve: One requirement that I have is that I be able to describe
          the area into which things flow separately from the stuff
          that's flowing into it.
   Steve: Right now table is entirely wound around the content that's
          in the table. I don't want that
   Steve: I want to describe whatever it is without having the content
   several, supported by Template module
   smfr: Can you split content up between boxes?
   TabAtkins: Not currently. No non-rectangular regions and no disconnected
   TabAtkins: would like to add later
   howcome: Did you see the very first draft from 1997?
   TabAtkins: No, just seen since Advanced Layout just before it got
              split into Template
   <Bert> http://www.w3.org/TR/NOTE-layout
   <dbaron> As far as defining table layout, http://dbaron.org/css/intrinsic/
            and a spec that Markus was working on both define significant
            pieces of the width calculation
   <dbaron> I actually think I like the height calculation that IE6 does
            more than what Gecko does.
   * fantasai notes that you're probably the only one who understands
              the implications of that comment :)
   TabAtkins: I'm not doing box-to-box flow in order to be conservative
              in level 3
   TabAtkins: I think it would still be useful
   ... printing ...
   TabAtkins: Printing does bring up other issues. It does matter.
   non-rectangular layout is difficult if multiple parts have flexible height

   TabAtkins: Next layout topic
   TabAtkins: Also related to table layout
   TabAtkins: In my current use of tables, I often want to set up a ton of
              things in a grid
   TabAtkins: but in my markup they're just a linear progression
   TabAtkins: and I want them to fill through and automatically find the
              right number of rows
   TabAtkins: so like normal table layout except without set rows
   TabAtkins: either by filling the width of a space, or specifying a
              number of columns
   howcome: Another idea is columns first
   TabAtkins: also want to determine direction of cell flow
   TabAtkins: When you loosen constraints on tables, then tend to become
              more similar to flexbox
   TabAtkins: So does anyone theoretically object to these additions to
              table stuff?
               * flowing cells into rows without row containers
               * cell progression direction: changing direction, changing
                 into columns-primary
   <bradk> block-progression-direction to flow vertically, possibly
   dbaron: If you switching block-progression direction, you'll also
           switch the width and height algorithms
   dbaron: Do you mean cell-progression-direction as a subfeature of
           the cell flow idea?
   TabAtkins doesn't know
   howcome complains about being forced to change markup to do layouts
   howcome wants a property for determining whether table is column-primary
           or row-primary
   dbaron: One thing I liked about table height algorithms in IE6 is
           that they were much more similar to the width algorithms
   howcome: You also had an idea about saying which cells you want to
            start a new row
   TabAtkins: If you just want to fill to a specific width, then that
              doesn't work
   TabAtkins: but for other cases it works
   TabAtkins: you can use :nth-child to do a specific number of rows
   fantasai: A problem with fill to a width is that you layou out your
             table, splitting into say 4 cols
   fantasai: but then you find a really big cell and find you can only
             fit 2 cols
   fantasai: then you have to go back and relayout the whole table
   fantasai: (which is already a 2-3 pass algorithm)
   TabAtkins: Ok, maybe that's not a good idea then. Don't like
              iterative layouts
   <bradk> container has 'table-flow: rows(4)' to auto flow table-cells
           vertically into 4 rows, with as many columns as it takes.
   TabAtkins: you might also want to flow into multiple rows, but not
              line up column-wise
   TabAtkins: They flow and wrap around, and each row is height-equalized
   TabAtkins: can fake it with inline-block, but doesn't handle all cases
   TabAtkins: Can't justify to exactly fit the row
   <Bert> (We did have a tabulation proposal some time ago. It was
           dropped when leaders() could do 80% of that.)

   Tab shows an example layout
   alexmog: That's a multi-line flexbox
   TabAtkins: Almost
   TabAtkins: box-pack-justify and a flexbox automatically sets all
              margins to be equivalent
   TabAtkins: but if you want finer control voer that, you can't express
              it in those terms
   TabAtkins: you can't set flex on margins
   TabAtkins: I think that's only place where flexbox is lacking.. it
              lays out from the container's perspective but not the
   alexmog: that's the point
   alexmog: Everywhere else in CSS every element has its own opinion on
            how it wants to be laid out
   alexmog: Flexbox allows introducing simple or different layout
            algorithms because it doesn't interfere with anything else
            in the system
   * scribe missed something in the middle there
   alexmog: The layout is totally governed by the container
   alexmog: that's why it's a clean, easy-to-implement, easy-to-use spec
   alexmog: If you let it allows margin collapsing and everything else
            that happens in CSS, then you create a monster
   TabAtkins: I would like to dive down and try to design with flexbox,
              and then bring back anything I find that's insufficient
   TabAtkins: But I'm willing to put that off and do experimentation
   dbaron: I think box-pack is pretty rarely used in xul
   dbaron: What's used instead is having more nested boxes
   TabAtkins: I do something imilar to flexbox using table layout
   TabAtkins: For a horizontal nav, I'll use auto or fixed table layout
              on a <ul>
   TabAtkins: to either space out the links, or the space between the links
   TabAtkins: in the first case, the white space between them changes,
              but their centers are spaced evenly
   TabAtkins: auto layout almost equalizes the spaces in between
   Steve: You might want to wrap borders around that white space
   fantasai: You might want to flex the borders, or you might want to flex
             the padding
   TabAtkins: I handle that by either styling the <li> or the <a> inside it
   Steve: There's another piece of this. If had a set of inline-blocks and
          turned justification on
   Steve: The only place it could put space would be in between the inline-blocks
   Steve: The catch is, you really want some space on the ends to make it
          look right
   * fantasai likes her display: tab spec, it solves all these problems
   <fantasai> http://fantasai.inkedblade.net/style/specs/tabs/
   Steve: I'm asking you to think about it as justification
   Steve: There may be other places you'd like justification
   fantasai describes a catalog use case that should also be solved by this

   TabAtkins: One thing I want to do that I don't have much experience with
              is what web apps need
   TabAtkins: Because I'm experienced with web sites, but not web apps
   <Bert> (There are also Media Queries to deal with different numbers of
   Tab shows an example of a site he designed
   TabAtkins: Here's a bunch of questions.
   TabAtkins: I'm flowing this into three rows
   TabAtkins: Right now I can only do with inline-blocks, but that means I
              can't equalize their heights
   Steve: What's the difference between flexbox and flowing tables?
   TabAtkins: Not having a grid in both directions
   Steve: If I had something I could do this flowing in, having properties
          that could turn it into the grid...
   Steve: I guess what I'm trying to say is that I see less similarity to
          tables for flowing tables than to flexbox
   Steve: I would expect the flowing cells more in the flexbox world
   Steve: with additional constraints
   TabAtkins: That's why I said there seems to be a point where tables and
              flexbox come to gether
   TabAtkins: As you add more constraints to flexbox and reduce constraints
              in tables they get more similar
   TabAtkins: We could maybe add more possible constraints to flexbox, and
              have it look more like a table
   TabAtkins: instead of going from tables towards flexbox
   Bert: Question about your grid of questions
   Bert: I would bet that most people fill top-to-bottom, whereas you fill
         horizontally first
   Tab explains this is because that was the only way he could hack it up
       into a grid using existing features
   <anne> btw, live style sheet editing:
   Tab explains also why multicol + snap-to-grid wouldn't work: a large item
       would throw off the alignment
   Steve: I have a similar use case of parallel translations
   howcome: That's another good use case for column-major instead of row-major
   * scribe missed alex's comment
   TabAtkins: You'd run into the iterative layout problem fantasai pointed out
   howcome: Have you looked at line-stacking-strategy?
   <howcome> http://www.w3.org/TR/css3-linebox/#LineStacking
   TabAtkins: Not recently
   TabAtkins: One criticism is that it doesn't apply across blocks
   * sylvaing just heard howcome come up with display:clearance-or-whatever

   TabAtkins: Can you set line-stacking-strategy on body and have it apply
              to everything?
   ?: It's never been implemented
   Steve: InDesign in Japan does that (just not in CSS)
   howcome: It may not be the solution, but is something you should take
            into account
   TabAtkins: I think there's an interesting intersection of table,
              multicol, flexbox, etc
   howcome: I think it's great. Come with your youthful energy and work
            on this.
   Steve: Something to be said for people solving problems by not being
          aware they're unsolveable

<br enthusiam="yay!" ... >
* sylvaing was sadly not informed about the hakon tweetup in time or he
            would have brought stack of free MSIE EU documentation for
            the grateful crowd
* anne still wants his IE t-shirt

dbaron's Auto-Percentage Heights Proposal

   dbaron: So the way widths work, you have some container
   dbaron: Then you have something inside that has margin border padding,
           then something inside that
   dbaron: You have computation going in from the edge
   determining the available width, and then when you hit a percentage you
     take a percentage of that.
   dbaron: What we've said in the past is that percentage heights are just
           auto if the container is auto
   dbaron: But people want percentage heights to just work
   dbaron: There are several places where this would be more useful
   dbaron: One is multicol
   dbaron: You usually want to scroll horizontally off the screen instead
           of vertically
   dbaron: My idea is that, as we're doing layout, we keep an idea of what
           the available width is
   dbaron: You start with the width of the viewport, subtract out borderpadding,
           and just keep subtracting in, possibly replacing with a fixed width
   dbaron: If we did this for height as well, percentages could be useful
   dbaron: It's not perfect, but it gives you a default in cases where you
           need a good default
   alexmog: another use case is block progression direction changes
   dbaron: And there might be some use cases for doing this with flexbox
   <TabAtkins> also text direction changes (vertical text vs horiz text)
   dbaron: I'm not sure what we're doing with this, but I might try adding
           it under a vendor prefix in Mozilla.
   TabAtkins: Would it be possible to implement this as how actual
              percentages work?
   dbaron: Probably too late
   TabAtkins: as a different unit or something?
   dbaron: maybe
   dbaron: We could use this for height: fill
   dbaron: and maybe even height: content-fit
   dbaron: This would only get you the effect of 100%
   TabAtkins: you could expose fill through calc() and then you can get
              precentages that way
   dbaron: A good use case would be max-height: fill
   dbaron: for columns
   dbaron: So you fill the screen, and then start growing out
   TabAtkins: max-height: 100vh would also solve that case, right?
   dbaron: Assuming your columns are not in something overflow: scroll
   people seem to like this for height: fill

CSS2.1 Issues

   Topic: jd's followup to issue-156
   <plinss_> http://lists.w3.org/Archives/Public/www-style/2010Mar/0538.html
   discussion about the proposal
   fantasai: "Once the font family's weights are mapped onto the CSS scale,
              missing weights are selected as follows:"
   <fantasai> use that to replace the introductory sentence, then add jd's
              bulletted list
   RESOLUTION: jdaggett + fantasai proposal above accepted

   fantasai: Issue 107 - anonymous table boxes proposal is done, bzbarsky
              has approved this proposal, and it's ready for wg discussion
   fantasai: please review so we can discuss it later
   <fantasai> the wrapping on that sucks
   <fantasai> I will resend from a real email client when I get home


   <howcome> http://dev.w3.org/csswg/css3-gcpm/#setting-named-strings-the-string-set-pro
   howcome: I'd like to publish another a WD
   howcome: wrt env() function
   howcome: There was a question of how to get the date and time in the
            locale of the user
   howcome: There seems to be a widely-available strftime function
   dbaron: There's also JavaScript functions that have this functionality
   dbaron: I'm not sure if it's exactly compatible
   * fantasai hopes it is, that would be annoying otherwise
   <dbaron> https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Date/toLocaleFormat
            is a Gecko extension, not part of ECMA
   glazou: fwiw, toLocalString uses the language of the browser, not the
           language of the system
   dbaron disagrees
   Tantek and Steve want to format date and time
   howcome tries to explain that it's not the point of the feature
   dbaron: Some strftime things are local-sensitive and some are not
   Tantek: Your only choice in howcome's draft is to use the locale-specific
   * dbaron thinks "2010年03月31日 16時16分40秒" is a perfectly readable date format!
   Tantek: I prefer if the env() would return in ISO values
   Steve: I would too, but i"m not sure it's as useful
   Tantek: with hyphens
   howcome: So 2010-03-30
   bradk: Wasn't the point to do what the browser does now, but be able
          to style it further?
   Steve: I don't mind publishing as long as this is marked as an issue
   Tantek: You should start with something universal and expand from there
   bradk: I don't think it's bad. There's a reason why browsers print the
          locale-specific version. It's not our job to educate the world
          on universal time formats
   fantasai: You could call it localtime so that you can add other things later
   howcome: So local-time and local-date
   howcome: what if I want both?
   Tantek: local-date-time
   <tantek> my personal preference would be for ordinal-date (YYYY-DDD)
   <tantek> and on that note - I have to depart. thanks everyone!

   howcome: Simon proposed to say that border-clip* should go into borders
            and backgrounds
   fantasai: We agreed to add this for CSS4 Backgrounds and Borders
   discussion of where these features belong
   fantasai volunteers to pull this into css4-backgrounds
   ACTION: fantasai put border-clip into css4-backgrounds
   howcome: Can we agree in principle in publishing GCPM as WD?
   no objections
   TabAtkins suggests removing repeat
   Tab: I suggested it originally, and I think it isn't needed
   TabAtkins: Also, percentages should refer to the height for vertical borders
   <smfr> i also think that hyphenation should move
   Peter: ok, I think we're done

Meeting closed.
Received on Thursday, 8 April 2010 07:15:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:45 UTC