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

[CSSWG] Minutes and Resolutions Cupertino F2F Monday 2010-03-29

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 08 Apr 2010 00:14:46 -0700
Message-ID: <4BBD8266.7090405@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - RESOLVED: CSSWG TPAC meeting on 1&2 November 2010
   - Next CSSWG F2F tentatively planned for March at Mozilla offices
     in Mountain View, CA

CSS2.1 Issues

   - RESOLVED: Defer to Sylvain for resolution of Issue 60, Bert will
               verify when editing that the changes are only editorial.

   - RESOLVED: In paged media where there is no viewport, a 'fixed' background
               is fixed with respect to the page box and is therefore replicated
               on every page.

   - RESOLVED: Backport jdaggett's css3-fonts text about 'bolder' and 'lighter'
               values of 'font-weight' into CSS2.1.
               <LINK TO PROPOSAL>

   - RESOLVED: In font-weight section pull bullet 4 (hole-mapping) out of bulleted
               list and replace "typical mappings" from the sentence below it with
               "this mapping" to make hole-mapping rules normative.

   - RESOLVED: Accept fantasai's proposal to distinguish zero clearance from no

   - Long rehashing of discussion around Issue 71. No conclusion.

   - For CSS2.1 Issue 26, general agreement that 'height' on table cell should
     be a minimum height for the row, not a minimum height for an anonymous box
     wrapped around the cell's contents. dbaron to write proposed wording.

CSS2.1 Test Suite

   - Publication of test suite snapshots causing strain on W3C's server. Further
     snapshots will be tarballs (with .htaccess files for charset tests); latest
     snapshot will be hosted at current/

   - Aiming to publish Beta 1 (including all of hixie's tests, i18n's tests, and
     Mozilla's submitted reftests) in mid-April.

   - CSS2.1 must be in PR by September.

Vendor Prefixes and Stabilizing Propeties

   - Conclusion: No change in CSS process. High-priority items should be extracted
     from low-priority items into separate specs to facilitate faster progress.

Status of Specs

   - CSS Styling Attributes waiting for response from SVGWG.
       LC comments: http://dev.w3.org/csswg/css-style-attr/issues-lc-2009
     Should create tests for common parsing mistakes.

   - Media Queries has many submitted tests in various formats. Waiting for someone
     to turn them into a test suite. Chris Lilley actioned to find tests and check
     them into test repo.

   - CSS Namespaces needs implementation reports. Daniel Glazman actioned to create

   - CSS3 Paged Media pending a lot of work before another Last Call.

   - Backgrounds and Borders pending test suite. fantasai to set up test suite with
     some tests, Mozilla will submit their existing tests.

   - CSS3 Color pending resolution of some non-trivial LC comments.
       Issues List: http://wiki.csswg.org/spec/css3-color

CSS3 Backgrounds and Borders Issues

   - RESOLVED: Add 'content-box' value to 'background-clip'

   - RESOLVED: Allow setting 'background-origin' and 'background-clip' in shorthand
               using [ border-box | padding-box | content-box ]{1,2} where one value
               sets both, two sets origin then clip.

   - RESOLVED: Change background shorthand to require position immediately before size:
               <bg-position> [/ <bg-size>]

   - RESOLVED: Proposal 3 accepted to drop recommendation for gradient corner blends

   - RESOLVED: Add simple (shadow border-box as if opaque) version of 'box-shadow'
               back to css3-background.

   The changes above will all require a return to Last Call.


   Discussed proposal for env() content function to return data about user's environment
   such as the file location and the current date/time. Discussion continues on Wednesday.


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

   Tab Atkins
   David Baron
   Bert Bos
   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
   Steve Zilles


ScribeNick: TabAtkins
   <sylvaing> http://wiki.csswg.org/planning/cupertino-2010
   plinss: Anyone with new topics?
   plinss: k, no new topics.

   plinss: First topic, TPAC. Need to set our dates.
   ChrisL: Request for monday/tuesday?
   glazou: Yes, from szilles and others. Want to make sure everyone is
           available for nov 1 and 2.
   glazou: Two hotels around the venue, Hilton and something else.
   glazou: Early rates, roughly 110 euros/night.
   glazou: Cheaper in the center of Lyons, but it's further away, and
           no easy connection via public transport.
   glazou: Unless there's a strong objection to monday/tuesday, we
           should let the w3c know.
   RESOLVED: CSSWG meeting is on November 1 and 2.

   glazou: We also need to discuss at some point the dates/location of
           first meeting in 2011.
   glazou: Who's willing to host in 2011?
   dbaron: There's a bunch of us who could host in the Bay Area.
   glazou: Probably fair to host in Bay Area after 2 meetings in Europe.
   dbaron: I'd be happy to host. (Mozilla)
   howcome: Seems to be too early to set up dates yet.
   glazou: Anytime in March is good. No good in February.
   dbaron: MIT spring break is march 21-26, and thus probably the AC
   glazou: So, if we meet on the last week of March, or 2nd or 3rd week,
           it would be better.
   <dbaron> Easter 2011 is April 24
   glazou: Let's stick with the idea of a March meeting hosted by Mozilla,
           and move on for now.

CSS 2.1 issues

   <plinss> http://wiki.csswg.org/spec/css2.1
   fantasai: Start with issue 60.

   <plinss> http://wiki.csswg.org/spec/css2.1#issue-60
   sylvaing: Issue 60 is from Anton Prouse and issues about z-index and stacking.
   sylvaing: There is no interop issues, it's mostly just cleanup and making
             sure that different parts of the spec agree.
   sylvaing: I suggested minimal changes, and he accepted most of them, there's
             just a few things left. I think we can get it closed in a few days.
   sylvaing: Mostly it's just terminology and a few other things that are
   sylvaing: Like intermixing "stacking order" and "painting order" and such.
   sylvaing: So, mostly editorial. We'll try to close it.
   sylvaing: In 9.9.1, there are a few errors, but browsers follow Appendix E,
             which is the important one.
   howcome: Seems like it's more than editorial, like #4 there.
   sylvaing: Yeah, #4 was the one actual error where 9.9.1 is out of sync with
             appendix E, but browsers do the right thing there.
   szilles: My suggestion is that we reaffirm that Appendix E is the normative
   howcome: Don't we already say that somewhere?
   szilles: I think we do, but it wouldn't hurt to affirm it as a Working Group.
   plinss: So we're agreed to accept Sylvain's changes?
   RESOLVED: Defer to Sylvain for resolution of Issue 60, Bert will verify
             when editing that the changes are only editorial.

   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-69
   <fantasai> In paged media where there is no viewport, a 'fixed' background
              is fixed with respect to the page box and is therefore replicated
              on every page."
   bradk: Should we mention something about box-decoration-break wrt fixed
   Arronei: Not in 2.1, but we'd have to in 3.
   szilles: What about bleeds?
   fantasai: Not addressed here. Backgrounds on the page box may bleed, but
             not on the document.
   howcome: There is a bleed property in gcpm.
   RESOLVED: In paged media where there is no viewport, a 'fixed' background
             is fixed with respect to the page box and is therefore replicated
             on every page.

   fantasai: Did we want to do #71?
   Bert: I'm in the process of responding to that, but have email troubles.

   fantasai: issue 73, peter was supposed to write a note?
   ACTION: Plinss find or write note for issue 73 by this afternoon

   plinss: Issue #111
   <smfr> http://wiki.csswg.org/spec/css2.1#issue-111
   plinss: Font-weight bolder/lighter, synchronize with css3?
   fantasai: Don't have a strong opinion on this.
   TabAtkins: So Daggett's suggestion was to make bolder/lighter act as if
              there were only four weights.
   ChrisL: As long as you can get to the other weights someway.
   szilles: This isn't great, but it's less bad than others.
   Bert: This is the same text as in the Fonts module?
   szilles: Yes.
   Bert: I'm okay with that.
   szilles: Obvious issue is, what do current browsers do with this?
   arronei: Currently, we test by having a list, and see if it's lighter
            or darker. Purely visual.
   szilles: Does the suggested algorithm keep this same behavior?
   Arronei: Should.
   RESOLVED: Accept Daggett's changed (from Fonts), back into CSS2.1.

   plinss: Related is issue 156.
   fantasai: ChrisL says "I'd prefer to see the mapping made normative."
   fantasai: Different mapping from issue 111.
   <fantasai> http://www.w3.org/TR/CSS21/fonts.html#font-boldness
   <fantasai> last bullet in the list
   <fantasai> "If there are fewer then 9 weights in the family"
   ChrisL: above that, it says "in typical cases", which makes it untestable.
   ChrisL: So, I'd like to drop that sentence.
   fantasai: OpenType fonts use a numerical scale, but they may not line
             up with multiples of 100.
   ChrisL: 4th bullet gives you a more precise description of that.
   ChrisL: I've seen things like a font with weights like 400 and 250,
           and that's fine. 200 and 300 aren't mapped explicitly.
   fantasai: You might actually want to map the 250 to 100.
   ChrisL: No, that'd expose more weights, but would put them in the
           wrong place. If you need precise mapping, just use @font-face.
   plinss: I think certain platforms made fonts map their weights wrong
           to get around bad heuristics.
   ChrisL: I haven't seen platform-specific weight tables like that.
   fantasai: I'm happy to make bullet 4 normative, but I'm less convinced
             about the other rules being normative.
   fantasai: I think mapping fonts to weights can be messy, and we
             shouldn't define that in css 2.1
   fantasai: But after the font has been mapped into the CSS font-weight
             scale, then we can follow the guidelines in bullet 4 to
             find missing weights.
   fantasai: That seems consistent.
   fantasai: The rules before that are about establishing the scale,
             and needs to be flexible to accomodate whatever twisted
             things we get into with fonts.
   * dbaron wonders if jdaggett should be around for this discussion
   fantasai: So the specific changes for this would be to pull bullet 4
             out of the list and remove "default".
   Chris: Also replace "typical mappings" from the sentence below it
          with "this mapping"
   RESOLVED: Proposal above accepted.

   plinss: Next is issue 114.
   fantasai: let's defer until dbaron is back.

   plinss: Issue 115
   fantasai: Summary should be "Zero clearance should be distinguished
             from not having clearance".
   fantasai: There are some cases in which you have clearance, but it
             calculates to 0, and the spec isn't clear about distinguishing
             this from no clearance.
   fantasai: Some things happen when there isn't clearance (margin collapsing,
   fantasai: So these other behaviors should still trigger when there is
             clearance, even if the value happens to compute to 0.
   alexmog: Any interop issues?
   plinss: Do we have testcases for current behavior?
   fantasai: I doubt we need any. It would require very unnatural code.
   fantasai: (to make 0 clearance act like no clearance)
   plinss: So do we have tests for clearance showing interop?
   fantasai: Sorta. Clearance is not the most interop portion of the spec.
   arronei: According to test cases, we do have at least two browsers agreeing.
   alexmog: I'm not sure if the first change is just about this issue...
   fantasai: Check the second email, it overrides that.
   fantasai: We'd take everything *but* the first change from the first
             email, and then all the changes from the second email.
   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-115
   <fantasai> all but the first change in http://lists.w3.org/Archives/Public/www-style/2009May/0186.html
   <fantasai> plus changes in http://lists.w3.org/Archives/Public/www-style/2009Aug/0394.html
   <fantasai> http://fantasai.inkedblade.net/style/specs/css2.1/zero-clearance
   RESOLVED: Accept fantasai's proposals for issue 115.

   <br type=coffee>

   plinss: Bert sent an email for issue 71.
   Bert: We discussed this a year ago, and I looked at the minutes for
         that meeting.
   Bert: If you find at @-rule in the middle of a declaration block,
         the rule says to ignore the @-rule, but you *want* to ignore
         the whole block.
   Bert: I think the error is the rule for ignoring @ keywords is meant
         for the rules, not declarations.
   Bert: So I suggest to make that explicit.
   <Bert> http://lists.w3.org/Archives/Public/www-style/2010Mar/0485.html
   <fantasai> body {
   <fantasai> @foo {}
   <fantasai> background: green;
   <fantasai> }
   <fantasai> Does that handle this?
   fantasai: We wanted the rule to stop ignoring at the close brace.
   plinss: Is that what we want?
   plinss: In paged media, we have @page which can be mixed with other @ blocks.
   fantasai: Right; right now the rules say the background should *not*
             be green - they say we should ignore until the semicolon.
   plinss: So you want the background:green to apply.
   fantasai: Right.
   Bert: My proposal is to do what CSS 2.1 says. I thought that's what
         we decided last year.
   Bert: Which would mean we ignore up to the semicolon, so there would
         be no green.
   plinss: Any @ keyword followed by a block or a semicolon should be
           ignored up to the next block or semicolon; we don't need to
           go farther.
   howcome: Is that what browsers do today?
   Bert: Yes.
   plinss: So existing browsers would ignore the background:green?
   <fantasai> body { color: @foo {} background: red; }
   <fantasai> body { @foo {} background: green; }
   glazou: Right, that should be ignored up to the semicolon, since it's
           inside the value of color.
   glazou: But we didn't discuss @ rules inside @ rules.
   fantasai: That's not what issue 71 is about.
   <fantasai> body { color @foo {}: red; }
   fantasai: After you start a declaration, as soon as you see a property,
             the @ rules become invalid tokens.
   anne: In CSSOM, at-rules always have to come at the end or the start.
   Bert: I thought we resolved in css3-page that the @rules come after
         the declarations
   plinss: We have the problem of the existing behavior.
   bradk: But changing existing behavior won't break any pages.
   howcome: What's the value of fixing this in 2.1?
   plinss: Compatibility with CSS3?
   anne: We need to know the parsing rules.
   howcome: If we decide it now, we could put it in css3.
   glazou: We have only one parser. It will be the same in 2 or 3.
   dbaron: The forward-compatible rules should be the same in all levels
           and should not change.
   howcome: I can probably live with fixing it.
   Bert: But if you start with / or something, it would not be green.
   glazou: But @ is an acceptable token inside a rule. A / is not.
   glazou: @page is a declaration block.
   plinss: It's something new, a mixed declaration and @ block.
   anne: Bert is right.
   anne: Declaration blocks don't currently have the notion of an @ block.
   Bert: I don't understand why we want to keep the @page construct,
         because that's where the error is.
   fantasai: @page is deployed.
   Bert: So is this.
   fantasai: @page is deployed *and used*. This error isn't used.
   fantasai: There are multiple impls. HP, Canon, Prince
   fantasai: Antenna House and Epson.
   anne: Question is, do we want to change the parsing to allow @ blocks
         inside of declaration blocks in the future?
   howcome: We can do cool stuff with it, and we can create nightmares.
   ChrisL: I'd like to see named stylesets, bundles of properties applied
           at once.
   howcome: You want to represent these structures in the object model?
   anne: Yes. [explanation of @page stuff]
   howcome: That's a special fix for @page. We're talking about generic things.
   anne: Yeah, if it was generic, we'd want a generic structure that
         @page could inherit from.
<RRSAgent> logging to http://www.w3.org/2010/03/29-CSS-irc
   anne: We have the problem for @page, for what goes inside of @page,
         that we need to solve one way or another.  We can make it
         special or we can make it generic.
   Bert: I proposed some time ago to create a 3rd type of block that
         would allow @page.
   Bert: But I think people wouldn't want that.
   anne: That wouldn't solve the earlier problem, the background wouldn't
         be green.
   Bert: Right, but it would let you do what @page wants.
   plinss: I'd prefer to see, if we see an @ rule, we parse it as a block,
           throw it away as invalid, and don't trash more than that.
   Bert: But that's inconsistent.  Any other unknown token would throw
         away until the next semicolon.
   szilles: @ already has the role of being special.
   glazou: I think we agree that if an @ occurs inside a value isn't an
           @ rule.
   glazou: Frex, if the first token inside the brace is an @ token, we'd
           like it to be an @ rule.
   Bert: If that's a change, we can't do it.
   glazou: It's something new that wouldn't break anything.
   Bert: It's in the spec.
   howcome: This is a change in the eternal grammar.
   anne: It doesn't change valid stylesheets.  I think it's fine.
   Bert: We have the error-recovery rules for consistency; you're changing
         the rules, so you're losing consistency.
   glazou: We are fighting about extensibility all the time.
   Bert: Things like adding to a shorthand is different, it fits in the
   Bert: Show me a place in CSS3 that is incompatible with the
         forward-compatible rules.
   plinss: @page
   ChrisL: @page is interoperably implemented.  I don't see the benefit
           of changing it; we should allow it, and use the extension
           point it allows to do new things.
   howcome: This is a change in the eternal grammar, but we don't really
            have a great use-case.
   howcome: A green background isn't a good use-case.
   howcome: It's interoperable today, I'm not sure we should change it.
   howcome: We're suggesting this change to get a generic extension mechanism.
   plinss: We have @page, which allows intermingling of @ rules in a
           declaration block.
   plinss: If it's *only* valid here, with special rules and special error
           recovery, that's very surprising.
   howcome: Do we allow @page at the place where we're talking about?
   <alexmog> adding a semicolon to the use case makes it green, interoparably:
             body { @foo {}; background: green; }
   plinss: No, not right now.  But @page acts like a declaration block, and
           allows more @ rules in it.
   glazou: [gives an example showing @page]
   plinss: If error-recovery from @foo inside @page's declaration block is
           different from in other declaration blocks, that's very surprising
   glazou: In @page, if you see another @page{}, it parses to that } and
           throws it away, allowing the next rules to work.
   glazou: But if you have @page{ @foo {} background: green; }, the background
           is thrown away.  That's very surprising.
   plinss: The problem is that an unknown @ rule at one point in the stylesheet,
           it parses to the }.  If you put it at another spot, and it doesn't
           parse to the }, that's weird.
   dbaron: We already have that in some places.  If an @rule appears in a
           value, or in a selector, it just makes an invalid value or selector.
   <dbaron> ... never mind what I said
   szilles: What anne just pointed out, if we have a single recovery mechanism,
            CSSOM can have a generic recovery mechanism.
   glazou: Non-generic means one parsing impl for @page, and another for other
           @ rules.
   glazou: That's ugly.
   <fantasai> We have different parsing of @keywords in different parts
              of the style sheet with or without the change we're proposing.
   <fantasai> For example, @keyword inside a declaration is still ignored as
              an invalid token
   <fantasai> However, having different parsing rules within a declaration block
              depending on whether the declaraiton block is inside @page or
              elsewhere, that is confusing
   <fantasai> and it is a burden on implementors to implement two different
              types of error-recovery
   alexmog: I'm agreeing with what Bert is saying.  I'm not seeing use-cases,
            but we have interop against it.
   <anne> advantages: 1) consistent rules for authors 2) one code path for
   alexmog: We'll have syntax that is ignored in older browsers but paid
            attention to in newer browsers.
   alexmog: We can just add a semicolon to the end of the @block and all
            browsers ignore it.  It's not the prettiest, but it achieves
            the goal.
   anne: Advantages is consistent rules for authors, and implementors.
   alexmog: How much time until browsers have changed sufficiently to allow it?
   TabAtkins: No more time than it would take for any new @ rule to be usable.
   plinss: He has a good point.  If we introduce a new @ rule, then authors
           using it will have their next declaration swallowed in older browsers.
   anne: But can't it sometimes be a start of a selector then?
   fantasai: No.
   anne: If you recommend putting a semicolon after every @ rule, it is
         the start of a selector, and you don't get a green background.
   anne: IE "@foo {}; body { background: green; }" kills the body block.
   Bert: Oh, no, not ; after everything.
   anne: I think we can just recommend that authors put the @ blocks at
         the end of the declaration block.
   plinss: I think it will be really confusing if you would recommend
           putting ; at the end of @ blocks inside a declaration block,
           but not at the end of ones outside a declaration block.
   Bert: I think we made a mistake on @page, not in the grammar.
   plinss: I think we made a mistake in the grammar, instead.
   fantasai: I think you can't stick an @ rule without braces is invalid
             inside a declaration block in the core grammar.
   fantasai: We have some options.  We could do nothing, which means no
             @ rules inside declaration blocks ever.
   fantasai: And then just have Paged Media declare that @ rules have to
             be at the end.
   plinss: The problem is that the longer we put it out, the more
           entrenched we'll get.
   Bert: Not expensive?  It's been in the spec for years!
   anne: What kind of implementations are you thinking of?
   Bert: TVs, etc.
   glazou: They're all consistent right now, though, so nobody uses it
           anyway.  It can't even be used as a browser selector.
   plinss: The problem isn't that it's an error now, but in a few years
           when we have a spec that uses @ rules in that area.
   anne: In a few years we'll have an upgraded set of browsers.
   szilles: So older browsers will throw it away, so nothing weird.
            Anne observes that if you put them at the end, it will
            prevent any rules from being dropped.
   Bert: So let's just put them at the end.
   fantasai: It's still invalid by the grammar.
   howcome: Eternal grammar isn't 'eternal', but I think it should
            still be harder to change than just writing a spec that
            says something different.
   howcome: We should have a very good reason to do it, and I haven't
            seen that reason.
   szilles: It simplifies the CSSOM model, for one.  It simplifies
            parsing for CSS.  It simplifies parsing for authors.
   <TabAtkins> @mixin(border-rules)(n) {
                 -moz-border-radius: n;
                 -webkit-border-radius: n;
                 border-radius: n; }
               div{ @mixin(border-rule, 8px) }
   Bert: Why do you need an @rule in the one place where it's not allowed?
   plinss: Because @rule already has rules for swallowing things to the
           end of a block.
   glazou: If you remember the time before CSS2, we didn't have @page.
   glazou: Declaration were *only* for style rules.  When we came up for
           @page, we suddenly had a new place for declarations.
   glazou: We want to be able to reuse an existing construct in the same way.
   glazou: It would open up a new type of contributions for authors that
           we can't usually do.
   Bert: Imagine changing XML.
   glazou: We did that when we added @media.
   Bert: That in 1998.
   szilles: I recommend the chairs take a straw poll.
   anne: And the options are 1) special handling of @page, or
         2) generic handling?
         and 3) require at-rules at the end for @page
   plinss: Given the current definition of @page, legacy handling would
           mean swallowing @margin rules inside of it, because @page
           contains a declaration block, which doesn't allow @ rules
           inside of it.
   Bert: 4th proposal, which has no chance, is to change Paged Media.
   Bert: And pull out @margin rules from the @page blocks.
   fantasai: They should have probably been outside from the beginning,
             but right now we can't change them.
   howcome: Where would you put them if they were outside?
   <ChrisL> CSS the Eternal Temple http://i40.tinypic.com/2nlwrjn.jpg
   howcome: [illustrates the change]
   <Bert> (One proposed change is in 13.2 say:... followed by a block
           of declarations <ins>and at-rules</ins>.)
   fantasai: Yeah, but we've got multiple implementations in printers,
             and so it can't be changed now.
   plinss: What's the point of putting @ at the end?  It seems like an
           arbitrary place.
   fantasai: It makes it clearer how inheritance works.
   howcome: So how do we deal with @page containing @top-left and such?
   Bert: Right now, we don't.  It's just invalid.
   Bert: We could create a special thing, not a declaration block,
         that would allow it.
   plinss: I'm reading the parsing rules, and I'm not seeing anything
           in CSS that says special handling of @ rules depending on
           the position.
   plinss: It doesn't say we only do this based on where it was.
   Bert: Right, but we discussed that it should behave that way.
   plinss: Please show me in the spec where it says it should behave
           the way you say it should behave.
   Bert: The two points above that.
   Bert: The question is only if there is an exception if the @ keyword
         appears right after a semicolon.
   dbaron: We don't specify what happens when the formal grammar
           disagrees with the prose.
   plinss: But the formal grammar doesn't define the recovery rules,
           only the prose does.
   dbaron: we usually go with whatever's more specific
   howcome: What if we used ::top-left or something?
   fantasai: Should have been @page::top-left, but shrug.
   Straw Poll:
   1) Generic Handling
   2) Special handling for @page in any order (current spec)
   3) Special handling, but @rules at the end.
   4) Change Paged Media to nuke margin boxes and rewrite @page.
   smfr: 1
   anne: 1
   szilles: 1
   <bradk> 1 generic
   dethbakin: 1
   sylvaing: abstain
   alexmog: 3 or 4, whatever doesn't change CSS 2.1
   ChrisL: 1
   Bert: Prefer 4, second is 3.  could also live with 2.  Can't live with 1
   arronei: 1
   <sylvaing> sylvaing abstains in the absence of a use-case
   fantasai: anything but 4, defer to dbaron
   dbaron: 4
   bradk: 1
   TabAtkins: 1
   glazou: 1
   plinss: 1
   howcome: 3
   dsinger: 1
   <fantasai> I think HP would raise a formal objection for 4
   glazou: Twelve for #1, three or four for 3 and 4.
   dsinger: We have agreement on *not* 2.
   plinss: And we can't do 4 because of existing impls.
   glazou: Existing impls do 2, so we're rejecting the current impls!
   fantasai: Not sure if existing impls do 2, maybe they do 1?
   ChrisL: How would you tell the difference?
   fantasai: Just pop my testcase into a supporting impl.
   <anne> <!DOCTYPE html><style>  body { @foo {} background: green; } </style>
   <ChrisL> it would be good to gather that implementation experience
            for printers that currently handle @page
   body {
     @foo {
     background: green;
   glazou: People will write it like Tab has, what will they expect?
   howcome: Prince considers this an error, and doesn't show a green background.
   fantasai: So it implements 2?
   anne: Or 3, we can't tell.
   plinss: Elika, can you test with your printers and get back to us?
   fantasai: Would be good to get AH.  Can we ping Murakami-san?
   fantasai: 3 would just mean normal 2.1 error-recovery mode.
   plinss: We'll come back when we get more implementations.
   howcome: Is there anyone that can't live with 3?
   anne: #3 is actually pretty weird.
   anne: So if you had @ rules, normal rules, then more @ rules, presumably
         you should ignore all the normal rules since the appearance of
         the @ implies the end?
   howcome: I think we can live with #3 now, and then make #1 valid later.
   dsinger: Can we write that we can possibly allow #1 later?  Warn people
            about it?
   plinss: I don't think there's any point to saying "Sometime in the future,
           we might add future-proofing."
   <ChrisL> :)
   dsinger: No, just that we might add a feature in the future that may
            require more generic handling, so don't depend on certain
            types of handling.
   howcome: There is no hole right now.  You're creating a hole and then
            insisting it needs to be filled.
   anne: Paged Media doesn't actually require them to be at the end.
   plinss: In my perspective, it's a bug in 2.1.
   plinss: In 2.1, we say when you see an @rule, swallow until the next
           block or semicolon.  We don't say to do that only at the rule
   plinss: We need to make this clear one way or another.  Bert's proposal
           is to say that applies only at the ruleset level, most others
           are saying apply at all levels.
   howcome: We have impl issues with that.
   plinss: We have an existing spec that needs @rules like this, and at
           least two more ideas I know of want that.
   Bert: But no one implements it like that anyway.
   plinss: Right.  But my reading of CSS is that you throw away an invalid
           @ rule as a unit.
   Bert: Only at the toplevel.
   plinss: But CSS doesn't say that.
   howcome: This is a new situation.  Bert is arguing *for* the browsers,
            Peter is arguing against?
   plinss: This isn't progressing.  We'll get more examples.  Until then
            we're not convincing anyone.

szilles: Can we set a time for jdaggett's call?  By my calc, 6am in
          Tokyo is 2pm here.
szilles: Is 3pm okay for us (7am for him)?
plinss: We have a lot of things for him to weigh in on.
plinss: I'd like him as early as possible.  I suggest we ask him when he's comfortable.
szilles: And then I"ll ask another Adobe employee to attend.
<br type=lunch duration=1h>
ScribeNick: fantasai

   dbaron: The way the spec currently says that vertical-align in table
           cells works is
   dbaron: You have a table
   dbaron: like this
   dbaron draws a table with 2 rows 2 cols
   dbaron: And you have a table cell likes this
   dbaron draws a cell box in the upper half of the first cell
   dbaron: The spec says vertical-align aligns the cell box inside the cell
           and it says that the 'height' property sets the height of a cell box
   dbaron: Suppose it says the cell height is 200px
   dbaron: The cell box will be 200px
   dbaron: and if the row is 200px high
   dbaron: the cell box stays put, and its contents are clearly not
           vertical-align: bottom
   dbaron: Nobody does this, everybody aligns the contents to the bottom
   dbaron: There are 2 possible solutions here, with different implications,
           and different browsers pick different ones
   dbaron: One alternative is to say that instead of 'height' setting the
           height of the cell box, it sets a minimal height for the row
   dbaron: The other solution is to say that you have two boxes
   dbaron: one of which wraps around the content, the other one of which
           wraps around that, and vertical-align aligns both of them,
           but the height only sets the height of the outer one
   dbaron: The tricky cases are where you have baseline alignment
   dbaron: You can get a case where baseline alignment requires more space
           than either cell would require alone
   dbaron: e.g. if you have a large-text box of auto height
   dbaron: and a small-text cell of large height
   dbaron: the baselines align
   dbaron: but the second box extends way below the bottom of the first
   dbaron draws this on the board
   <css_projector> http://dbaron.org/css/test/2010/css21-issue-26
   dbaron shows http://www.brunildo.org/test/td_height1.html
   fantasai: I would not expect vertical-align to increase the size of
             the cell there
   fantasai: I would expect height to set the height of the same box
             that you paint borders and backgrounds on, not on the
             anonymous content holder inside it
   <smfr> http://www.w3.org/TR/CSS21/tables.html#height-layout
   fantasai: Does height include the padding?
   fantasai: border-widths?
   Looks like height in Mozilla is a border-box height
   fantasai thinks we should say that the height sets the border-box
            height of the cell box. Then the contents of the cell are
            wrapped in an anonymous box, and that is aligned inside
            the cell
   Alex: What do Mozilla and WebKit do for flexbox?
   dbaron: I'm not so concerned with that
   Steve: So you have two boxes, one that most properties apply to,
          and then the box that wraps the contents of the cell, that
          gets vertical-aligned
   Steve: The first box has border, padding, etc.
   dbaron: We should figure out what we want so that someone can write
           a proposal
   dsinger asks a question
   dbaron: baseline alignment is a relative thing. You take all the
           cells in the row and baseline-align their contents.
   dbaron: If the height of the row is taller than the height of the
           aligned set of content, it's undefined what happens
   Steve: So your question is that ... can we give names to these things?
   dbaron: One of them is called the cell box, but it's not what you'd
           think of as the cell box
   dbaron: The simplest change it to go with IE and Opera and say that
           'height' on the cell sets the minimum height of the row
   <anne> http://dev.w3.org/csswg/css3-tables-algorithms/Overview.src.htm
   howcome talks about making a bar chart
   dbaron: An explicit height on a table cell does not cause even the
           contents of that cell from increasing the height of the cell
   dbaron: Everything's like minimum heights in tables
   Alex agrees with Opera's interepretation
   Steve: If you want the other behavior, you can put a fixed height
          on a <div> inside
   plinss: Shouldn't require markup changes for layout
   fantasai: This is the most intuitive interpretation.
   fantasai: If I was an author, I'd associate the height of the table
             cell with the height of the box that has borders and
             backgrounds on it, not some invisible thing inside it
   Simon: Hyatt doesn't really care which way this goes
   ACTION: dbaron write proposal for IE-Opera behavior for issue 26

   fantasai explains that the spec is unclear about what is allowed and
            what is invalid
   Arron has a bunch of testcases showing that results are very different
         across browsers
   There are two proposals for clarifying the spec
   one would make unquoted font names a series of identifier tokens
   the other would make them a series of nmchars tokens
   Chris suggests recommending quotes
   The spec already recommends quotes
   dbaron: right now in Gecko you have to escape or quote numbers
   several: Let's allow everything
   <ChrisL> everything but comma
   fantasai: I don't like that, because you have to have some exceptions,
             which is what we have already, and it's already causing
             interop problems
   Chris: How about making a grammar for what the prose already says
   discussion of what mistakes web authors are likely to make
   <ChrisL> some font families that might be useful for tests -
            "101 Dalmations" "3.14 Pi" "Twenty 4px"
   dbaron: right now the spec has document conformance reqs but no ua
           conformance reqs
   arron: If you run the testcases, you'll see a lot of constency
          except for numbers and brackets
   Arron to write up test results

<br type=cookies>

CSS2.1 Test Suite

   glazou: First issue is about inode strain on the server
   bert: it's not about space, it's our mirroring system
   Alex: Would adding another 15000 tests facilitate upgrading the system? :)
   Chris: It's generating emails to the mirrors for each file
   glazou: If solving this for w3.org involves more work for us on
           the test suite, let's just move.
   glazou: I suggest we do nothing and wait
   bert: I also have an action to get the issues list onto w3c servers
   Chris: The SVGWG had its working its files off-site on a company
          server, then that company got bought and the files disappeared.
          Took months to get the tar files back.
   fantasai, plinss: Our server is not controlled by a company, it's a
          personal account, funded by HP, but under plinss's name. So
          we won't have that problem.
   fantasai: We could create tarballs for the snapshots, just publish
             the latest expanded out.

   Arron: We're not getting a lot of traction on review of testcases
   Arron: It's something that needs to happen
   fantasai: Also people are reporting errors when they review, but not
             whether tests have passed their review. Makes it impossible
             to mark tests as approved.
   Plinss: We decided we'd drive reviews by people generating
           implementation reports
   plinss: And then people can object if they find test is wrong

   glazou: When will the test suite be complete?
   discussion between glazou and fantasai about scheduling test suite work
   fantasai aims to publish ts beta 1 in mid-April
   Arron: It should take each browser vendors 2 days of 8 hours each
          to run an implementation report
   Glazou: We must be in PR by September, keep that in mind

Vendor prefixes

   Bert: Why?
   glazou: There's been a bunch of discussion on www-style
   glazou: I don't think the current situation is satisfactory from the
           web authors pov
   glazou: On filters and web-authoring tools side it's hell
   Alex: Shouldn't be using experimental stuff until it's stable
   dbaron: I think we should be able to find a way to declare things
           stable until CR
   Steve: There is a way. It's called CR. It hasn't received enough
          review until then. It hasn't gone to last call
   Steve: If you need to, make smaller modules.
   <TabAtkins> @mixin border-radius(radius: 8px) {
   <TabAtkins>    -moz-border-radius: var(radius);
   <TabAtkins>    -webkit-border-radius: var(radius);
   <TabAtkins>    border-radius: var(radius);
   <TabAtkins> }
   <TabAtkins> .box-with-corners {
   <TabAtkins>    @mixin border-radius(12px);
   <TabAtkins>    border: 2px solid black;
   <TabAtkins> }
   <TabAtkins> ^^^ make an end-run around the issue with additions to syntax
   glazou: I think we should have a frozen status for features
   Steve: ... W3C process
   dbaron: The versioning process of CSS isn't a W3C process issue
   anne: What impl do or not doesn't have anything to do with process
   Steve: You should be at CR when you write the tests because that's when
          the spec is stable enough to write a test suite
   Steve: We have good examples where removing the prefix would have been
          a mistake
   Howcome: We have had decisions in the past, when we said they will never
            change again, even though they're not in CR. I think that makes
   Steve: The reason it doesn't make sense is that part of Last Call, which
          is the part you're living out, is to get review from people /not/
          in the WG. And you're not getting that review
   Tab: I agree with Steve. I think we should stick with this model.
   Bert: The problem is we do so many things simultaneously. We should focus
         on things that are stable and /finish/ them. Then we wouldn't have
         this problem.
   Tab: We could make vendor-prefixes less painful for authors we could use
        a mixins syntax
   Tab: This example is simple one, for border-radius.
   Tab: If one implementation had a slightly different syntax, you could just
        change it in the mixin definition
   Tab: And you only need to write it once
   Tab: every time you need border-radius
   glazou talks about HTML's versioning model
   Tab: I don't like HTML5's model. It's much nicer in JavaScript
   Tab: JavaScript can afford to be ugly because you can layer a nice api over it
   dbaron: I think the big problem is not the model, but the timing of how
           we've been advancing properties
   howcome: It's been a problem only for a few, more than one but only a few
   glazou: Whether it's a problem for a property depends a lot on how popular
           it is
   Alex: Isn't it a problem that we have an unprefixed 'zoom' property?
         It looks like a regular standard property but it isn't
   dbaron: We haven't changed our border-radius prefix because we don't
           yet match the current spec
   dbaron: Most of those issues are not even syntactic
   dbaron: There are a lot of requirements in the current spec that we
           don't implement
   dbaron: I had questioned at the time whether the spec needed to
           require things in that much detail
   howcome: I think you should drop the prefix anyway. Even if you have
            some bugs left. They're just bugs
   Brad: If we had dropped the prefix for border-image earlier, we'd be
         stuck with the old definition
   Brad: We wouldn't be able to make the changes I proposed.
   Brad: We thought it was stable.
   dbaron: I've heard comments from people who were unhappy that the
           prefixed versions didn't match the spec
   Steve: Why isn't macros, by any other name, a good solution to this?
   glazou asks questions that were answered previously
   the minute-taker will not repeat the answers
   plinss: If they have different behavior?
   <Bert> (One way to do mixins, especially usefule if you work with
           Ruby: http://sass-lang.com/ )
   Tab: If it's just syntactic, you can work around it. If you can't,
        then you're screwed anyway
   Steve: If they don't do what you want, dropping the prefix isn't
          helpful anyway
   Plinss: The problem with this is, what if I change something via JavaScript?
   Anne: Maybe you don't see it in JavaScript
   howcome: This saves people 30 seconds of copy-pasting. It's not
            really a problem
   howcome: I think this problem is over-rated
   <anne> I agree with howcome
   Tab: If we want to drop prefixes on something not in CR, we should
        pull it out into another module
   Bert: We did that with css3-backgrounds, we dropped box-shadow so we
         could move everything else forward
   Tab: Yes. That would solve this while giving us all the benefits of CR.
   Steve: We can solve this problem by focusing on what's important and
          pushing that forward
   glazou: You don't know whether something's going to be succesful when
           you design it
   some arguments that it doesn't matter, you'll find out quickly
   others that you can predict it for some things anyway
   Steve: Once you find out something is popular, then you progress it faster.
   glazou: If we accept the extra work to extract properties and push it
           forward, then it's not a problem
   Chris: Depends on how much of the spec is stable. If it's mostly stable,
          pull the unstable things out and move the whole thing
   Chris: If it's mostly unstable, extract the stable parts and push that
   Anne: Other WG's have pseudo-stable drafts that are implemented and
         shipped, and only take small changes
   Anne: It seems to work relatively well
   Steve: Yes and no
   -> offline
   glazou: If we have a high-priority set of properties, let's try to extract
           them to move faster

Status-type Stuff

Style-attr Status

   glazou: Last Call period ended. Need to check comments and write
           disposition of comments
   fantasai: I'm waiting for a response from SVGWG, other than that it's
             pretty much done
   dbaron: Should include tests for common problems
   dbaron: like braces around the declaration block

Media Queries Status

   glazou: CR period ended a few months ago
   glazou: We don't have a test suite, I think
   Anne: a lot of tests submitted, but no suite
   glazou: So, what do we do?
   Anne: We find someone to go through the tests and make a test suite
   howcome: We already found him
   howcome: Can't you do that?
   anne: I'm not sure I want to
   howcome: That wasn't my question :)
   anne: We have a lot of different tests, they're not all in the same format
   Anne explains some of the types of tests that were submitted
   discussion of how to test the 'grid' feature
   glazou: Are you able to handle the media queries test suite, or not?
   anne: I would rather not. I haven't done any work on it
   anne: the tests are posted to various mailing lists
   Anne: I'm sort of swamped with editing
   ACTION: clilley Find tests for media queries and check into test repository

Namespaces Status

   glazou: We're in CR, it is implemented
   dbaron: I think we fixed the one parsing bug we had
   glazou: We need implementation reports
   dbaron: If the bug is in the 2.1 implementation, can we say that the
           bug is in the 2.1 spec implementation and for the purposes of
           Namespaces it's a pass?
   <dbaron> Implementation report Firefox 3.6.2 Linux: all tests pass
   <dbaron> http://www.w3.org/Style/CSS/Test/CSS3/Namespace/current/
   ACTION: glazou make namespaces implementation reports

CSS3 Page Status

   fantasai: It needs a lot more work before another Last Call

CSS3 Backgrounds and Borders Status

   fantasai: Planning to write 10-15 tests to set up, then will be
             easier to accept submissions. Probably nothing complete
             until August F2F at the earliest

CSS3 Color Status

   dbaron: Some LC comments are non-trivial. We should go through the
           comments some time this meeting
   dbaron: The current editor's draft addresses most, but not all,
           issues. Haven't sent responses yet.
   <dbaron> http://wiki.csswg.org/spec/css3-color is the issues list

CSS3 Backgrounds and Borders Issues
ScribeNick: TabAtkins

   fantasai: 4 issues, somewhat related.
   fantasai: All effect the shorthand.
   fantasai: sylvain's issue was background-clip.
   fantasai: Start with background-clip, do we allow content-box?
   fantasai: As well, in the shorthand, I suggest that if *-box appears once,
             it sets both origin and clip, while if it appears twice, it
             sets origin to the first and clip to the second
   bradk: I wanted to do bg-size first, so I could bring up that we could use
          a slash to disambiguate this as well.
   bradk: [on board] Right now you've got like "/ <bg-size>".
   bradk: So apply that the same to origin/clip, so you could say, like
          "border-box / padding-box" or just "border-box" or just
          "/ padding-box".
   TabAtkins: I want to avoid / whenever possible, though.
   bradk: We're already using /s in various properties, border-radius, font,
   TabAtkins: In a lot of those, though, you're splitting apart lists of
              numbers, and it's *impossible* to tell where things start and
              end without the /.  With keywords you don't need to do that.
   anne: Other places with keywords, like overflow, don't need a /.
   anne: And background-repeat.
   bradk: You need *something* to separate bg-position and bg-size.
   anne: Yeah.
   bradk: You get some freedom with how you write things with the /
   anne: Is that freedom actually needed, though?
   TabAtkins: I don't think we need to generalize in order to solve the
              position/size issue.  Other places where we have a /, we
              definitely need it; other places where we don't, we
              definitely don't.
   fantasai: I think separating them would make things more difficult.
   fantasai: When you're parsing, you can just shove stuff into data
             structures directly.
   fantasai: You don't have to remember what has come before.
   fantasai: That's part of why Yves wanted to relax the restriction
             on ordering, so you just have to look at the previous token
             to see if it's valid to put in a bg-position, rather than
             having to remember that you had a size earlier in the rule.
   fantasai: position is always a position.  If size is completely absent,
             it's a position.
   bradk: Don't you have to read ahead to see if there's a size?
   fantasai: No, as soon as you hit lengths, you know it's a position.
             And then, later, you might see a slash denoting a size.
   Bert: I think the main issue is just one of readability.
   [discussion about human/machine parsability with a / anywhere in
    the rule versus / immediately before a size]
   TabAtkins: So can we add content-box to bg-clip, and accept the shorthand?
   strawpoll: Add content-box to background-clip?
   Abstain?  6
   Objections? 0
   RESOLVED: Add content-box to bg-clip
   RESOLVED: Allow setting bg-origin and clip in shorthand
   fantasai: Disallow "/size position", definitely.
   fantasai: Allow "position url /size" and "/size url position"?
   fantasai: Or restrict it to *only* "position/size"?
   RESOLVED: Change background shorthand to have "<bg-position> [/ <bg-size>]".
             (Position is required if you specify size.)

   <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Feb/0238.html
   fantasai: Small one about border-radius.
   fantasai: 1) Define gradient stops in more detail.
             2) Don't define color-transitions at all.
   howcome: So what was the problem before?
   sylvaing: Today with different-colored borders, you get a sharp border.
             If we want a gradient, we need a way that's interop across
   ChrisL: Currently the spec tells you where on the curve the midpoint is.
   ChrisL: I think we should still be able to get that, and I think that's
           enough to get a gradient.
   ChrisL: [describes a linear-gradient based one]
   sylvaing: Could we get it back through CR quickly with that?
   <ChrisL> in fact i descriped two gradients, one from the start color to
            the midpoint color and one from the midpoint color to the end
            color; both linear wrt *angle*
   sylvaing: I see it as a different issue.  I want to control my corners,
             and then I want to control my borders.
   fantasai: I think making it undefined is fine, and then we have an
             informative appendix illustrating some nice ways to join corners.
   szilles: The experience of leaving things undefined is that someone ends
            up defining them.
   ChrisL: I understand the argument of doing the simple thing now and the
           complicated thing now.  But what I don't like is some browsers
           having a sharp transition and you do a smooth transition because
           you think it looks better.
   dbaron: I haven't seen authors complain about this yet, but authors
           *do* complain about performance, and sharp vs gradients has
           performance implications.
   sylvaing: If we later do 45deg corners, you'll need a linear gradient, etc.
   fantasai: I'm fine with leaving it undefined right now, and we'll define
             it in level 4 and we'll be good.
   szilles: But we won't have that freedom after a little bit.
   dbaron: I think I'm okay with that lack of freedom.
   fantasai: If our browsers do something right now that authors don't like,
             we'll change.
   dbaron: sometimes it's best to let the market decide
   sylvaing: I'm fine with specifying sharp transitions, and I'm fine with
   <fantasai> Proposal is: "It is not defined what these transitions look like."
   Tab: I'm fine with explicitly undefined, being defined later possibly
        constrained by market forces.
   Chris: I would prefer it to be defined, but I can live with the other options
   arronei: From a testing perspective, I prefer defined.
   dsinger: If someone *requires* a particular effect, they can use a
            border-image, right?  I'm okay with leaving it undefined
            and waiting to see what people start hacking around it with.
   dbaron: We can define the shape of the border, we can define the limits
           of the transition, we just won't define what it looks like other
           than that.
   RESOLVED: proposal 3 accepted
   szilles: So all existing hard-edged impls match that proposal?
   glazou: yes.

   glazou: howcome, you have the floor for box-shadow
   howcome: box-shadow was removed to gain speed for the spec.
   howcome: We now have 4 interoperable impls of box-shadow, so I think
            we should put it back in.
   howcome: Or else put it in it's own spec.
   glazou: I have some tests, and it looks interoperable.
   howcome: [looking at MS people] I suspect they have something up their sleeve.
   sylvaing: We'd like to see it back in.
   howcome: So we have interop, why was it removed?
   TabAtkins: There were significant complications being suggested, to
              the point where it *was* going to slow the draft.  A very
              simple box-shadow, what we have interop on, would have been ok.
   howcome: My position is that we add it back in.  Simple list of lengths,
            a color, an inset/outset keyword.  Purely rectangular (module
   RESOLVED: Put the simple version of box-shadow back into B&B.

GCPM - env() function

   <plinss> http://dev.w3.org/csswg/css3-gcpm/
   <plinss> http://dev.w3.org/csswg/css3-gcpm/#string-set
   howcome: If you print in most browsers, the browser will put the time
            of printing in the margin box.
   howcome: The idea is to make it possible to get that info in CSS.
   <ChrisL> env(location.lattitude)
   <dbaron> Is this going to gradually turn into strftime?
   dbaron, yes.
   <dbaron> 2010年04月02日 vs. 2010-04-02 vs. 2/4/10 vs. 4/2/10 vs.
            2/4/2010 vs. 4/2/2010
   glazou: A long while ago, around CSS2, we had a proposal for a date()
           function, Misha Wolf (sp?) gave a long, excellent argument
           for why date is no good.
   szilles: How does the system know what to output the date as?
   glazou: From the system locale.
   szilles: That assumes the locale it is printed in is the same as the
            locale it is read for.
   glazou: That's the same problem that you *already have* with dates
           on printouts, you're just styling them now.
   [discussion of how Word does stuff/locale bindings]
   howcome: There is a way to just ask the system for the date, and
            env(date) would just give that.
   szilles: What's the use-case for this?
   howcome: Use-case is, when a browser prints a page today, they put
            the date on the printout.  This would give you control over that.
   szilles: I'm printing a document that's written in Armenian, and
            I'm going to distribute it to my Armenian friends.
   howcome: By adding this feature, we allow ourselves to turn it
            off as well.
   szilles: I could potentially turn it off with just a little checkbox
            in some preferences.
   TabAtkins: No browser lets you do that right now.  We can solve it
              through CSS.
   Bert: Some javascript to get at things from your environment (such
         as if you are counting in the jewish date) that you may not want.
   glazou: You already have (new Date()).toLocaleString().
   szilles: My issue isn't with whether you want url or date.  My issue
            is more the discussion from Mischa, where the date is a very
            dangerous thing.
   szilles: I don't think there's a such thing as the "date".
   TabAtkins: You're trying to add things to what we just want to simply cssify.
   <anne> javascript:(new Date).toLocaleString()
   <anne> Monday March 29, GMT-0700 2010
   smfr: Is the intent to limit it to Paged Media?
   howcome: No, it can go in content property, so it can go anywhere potentially.
   smfr: When is the date set?  Is it live?  Does it update when the
         page is refreshed?  What about if layout changes something?
   glazou: More detail is needed there.
   glazou: Sometimes when printing, the *username* is displayed on the printout.
           We shouldn't give access to that.
   howcome: So it seems like this is potentially a useful thing, but
            there are security and i18n concerns.
   bradk: Date, or date and time?
   howcome: We can do env(date) and env(time).
   plinss: Some printouts have the document title.
   howcome: You can already pull that from <title> using string-set.

   <smfr> http://dev.w3.org/csswg/css3-gcpm/#turning-elements-into-footnotes
   howcome: Small issue with footnotes.  If you're in the draft, look
            at example XXIV
   howcome: display footnotes stacked vertically, or flowed inline.
   howcome: My first idea is to use display on the footnote element
            that determines what it does here.
   howcome: But I think this is sorta inconvenient, as when you're
            floating an inline element you'd have to explicitly set
   arronei: What about float:footnote and float:inline-footnote?
            Then you don't have to mess with display.
   TabAtkins: I like that idea.
   bradk: And could we then do display: list-item on the footnote to
          auto-generate the marker.
   glazou: You cannot use list-item, because it precludes an inline footnote.
   howcome: Suggestion: Put display:inline on the @footnote rule, to
            switch the display type of the footnotes.  It's a bit of
            a hack, but display is otherwise unused in @footnote.
   <sylvaing> sylvaing has joined #css
   howcome: Input is great, we'll discuss more on the list.
   howcome: I'd also like a new editor's draft.

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

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