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

[CSSWG] Minutes and Resolutions 2010-04-28

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 30 Apr 2010 17:39:13 -0700
Message-ID: <4BDB7831.6000507@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - Arron's started adding metadata to tests missing data; expecting to
     be done in 2 weeks.
   - RESOLVED: Publish new Working Draft of CSS3 Template Layout module
   - Discussed inheritance behavior of calc(). No WG resolution, but
     dbaron and Rossen seem to agree on dbaron's latest proposal.
   - Nobody knows who's responsible for View Modes comments; chairs to
     sort it out.
   - Discussed empty media queries and the differing behaviors in CSS,
     HTML, and the OM. dbaron and glazou to write up a proposal for
     handling invalid queries and empty media lists in the OM.

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

   César Acebal
   Rossen Atanassov (Microsoft)
   David Baron
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   Chris Lilley
   Peter Linss
   Hĺkon Wium Lie (partial)
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2010/04/28-CSS-irc

ScribeNick: fantasai

Test Suite

   Daniel: Peter and I would like to know where we are at this point
   arron: I started work on adding the metadata
   arron: I should have half done by the end of this week, hopefully
          all done by end of next week
   arron: That would mean that all the cases that have not been put in
          due to metadata will be ready to publish in the test suite
   fantasai: I haven't done anything, but I think two weeks time is
             reasonable for preparing a publication

Template Layout

   Bert would like to publish a new working draft
   Bert: Mostly small changes, but would like to publish another draft
         to show it is still active
   Bert: Open question of what properties should apply to ::slot()
   Bert: Tab favors all properties, I prefer limiting the properties
   RESOLVED: Publish new WD of css3-layout


   <glazou> http://lists.w3.org/Archives/Public/www-style/2010Apr/0184.html
   howcome: It's a good question, what should be inherited from calc()
   dbaron: I had a proposal in one of the responses
   <glazou> http://lists.w3.org/Archives/Public/www-style/2010Apr/0256.html
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2010Apr/0258.html
   dbaron: Right now, calc() is only taking lengths or percentages.
           It doesn't take keywords of the properties
   dbaron: We haven't figured out what to do with things that are
           dimensionally invalid for the property
   dbaron: I suggest percentages transformed the same way they they're
           handled in the property
   dbaron: And all lengths converted to an absolute length
   dbaron: If we add keywords, they would be treated similar to percentages
   dbaron: So if you say calc(50% + 2em)
   dbaron: Then the em gets converted using the element's font size
   dbaron: The percentage gets calculated according to property rules
   <ChrisL> so the inherited value is the "most resolved" value which
            might be calc() ...
   dbaron: So font-size: calc(50% + 2em) is equivalent to 250%
   dbaron: But width: calc(50% + 2em) would inherit as calc(50% + Xabsoluteunits)
   glazou: It makes sense for a value to inherit the same way when it's
           inside calc() as when it's outside it
   <bradk> calc(50%) === 50%
   dbaron: We do want calc() to inherit reasonable because people might
           want to use it for properties that inherit by default
   Sylvain: So, people would want the formula to inherit, not the result
            of the calculation?
   fantasai: You don't want to inherit the calculation, because that
             would require you to do layout before inheritance.
   glazou: I'm not sure I like inheriting the formula
   fantasai: If you have width: 50%, you want width: calc(50%) to inherit
             the same way
   <Bert> (Currently, 'width: 50%' ... 'width: inherit' also inherits the
           percentage, not the calculated width, so not too different
           from calc(50% + 1em).)
   fantasai: If you resolve the formula to an absolute length, then it
             won't inherit the same way
   sylvain: Why shouldn't it behave differently? It has a different syntax.
   dbaron: Who is glazou disagreeing with?
   <glazou> dbaron: with fantasai
   <fantasai> <div class="a"> <div class="b"></div> </div>
   <fantasai> .a { padding: really big; }
   <fantasai> Say .a { width: 50% } resolves to 100px
   <fantasai> .b { width: 50%; } resolves to 25px
   <fantasai> .b { width: inherit; } currently also resolves to 25px
   <fantasai> You're suggesting that
   <fantasai> .a { width: calc(50% + 1px) }  (resolves to 101px)
   <fantasai> .b { width: inherit; }
   <fantasai> You're saying b should resolve to 101px
   <fantasai> rather than 26px
   <fantasai> you == sylvain
   Rossen: So, the response that David actually had, the latest one,
           saying that you basically inherit the calc and on the way
           down the inheritance you have two types of inheritance
   Rossen: So ems, you resolve the ems, and then inherit the value
   Rossen: Percentage values inherit all the way down as percentages
   Rossen; so percentages are resolved in your current space
   Rossen: That makes sense to me
   Rossen: If you have calc(50%) it inherits down as 50 percent
   Rossen: But calc(1em) inherits down as whatever 1em calculates to
           where it's specified
   Rossen: That's what I see in dbaron's response, and that basically
           confirms my understanding of how it should work
   SteveZ: So if I have an expression, it will calculate itself out
           unless it uses a percentage that would not be calculated
           out at that point if it were freestanding
   Sylvain argues that the 'calc()' syntax requests a different behavior
           from a user perspective.
   dbaron disagrees
   Rossen: The interesting example here, suppose we had calc(50% + 1em)
   <dbaron> I think calc() is about combining existing values, and
            those values should behave just like they do without calc().
   SteveZ: The surprise doesn't come from calc, it comes from certain
           values not being calculated due to layout being required.
   SteveZ: This is already an issue. calc() makes it more complicated
            because some values computed and others don't
   SteveZ: so it emphasizes the problem
   SteveZ: To me, calc() of some value should be exactly the same as
           that value alone
   fantasai: Does anyone here disagree with SteveZ's last statement?
   Sylvain: I think some people will expect that calc() computes the
            value and then inherits down.
   Sylvain: I don't think it's crazy that an average web author
            considers calc(X) should behave differently than X alone
   glazou: We have two ways of saying how calc() is working.
   glazou asserts that dbaron and fantasai and Rossen and sylvain
          have different proposals
   dbaron and fantasai don't understnad why he thinks they're disagreeing
     with Rossen
   <dbaron> What's the difference between these proposals?
   Sylvain: I'm not proposing something different, I'm just saying it
            may be confusing.
   Rossen: calc() is just like parentheses. You can put parentheses
           around a single value in an expression; it doesn't do anything
   Rossen: I'm fine with writing up a paragraph on this
   SteveZ: I think that the teaching thing is no worse than teaching
           exponents, when any number to the first power is the same
           as that number
   Sylvain: The functional notation creates some expectations
   SteveZ: I found dbaron's description hard to read, so Rossen, if
           you write it up I would prefer a better explanation of why
           percentages behave the way they do
   <dbaron> I think the essence of my proposal is that each leaf value
            within the calc() expression gets computed as though it's
            a value of the property.
   <dbaron> Except I worded it to allow for values that aren't values
            of the property.
   * fantasai can't imagine anyone inheriting calc on width.
   <bradk> width: calc(100% - <padding-amount>) is something I could
           imagine using, and inheriting

Selectors Serialization

   glazou: Is anne on the call?

RFC on View Modes

   <smfr> url?
   <Bert> http://www.w3.org/TR/2010/WD-view-mode-20100420/
   SteveZ: Who wrote the comments?
   Bert: i think we developd the comments together
   Steve: But somebody sent them
   glazou: Peter and Bert and I will sort it out after the call

Empty Media Queries

   <glazou> http://lists.w3.org/Archives/Public/www-style/2010Apr/0391.html
   Sylvain: The one thing was the definitions are in two different places
   Sylvain: I understand if we don't want to move backwards to fix that
   ChrisL: In the DOM, if you remove an attribute or if it has it's
           default value, you can tell the difference. Is that the same
           as here?
   Sylvain: The implementations of @media are inconsistent, and it is
            more inconsistent when you consider the markup side
   Sylvain: Right now we have the OM defined somewhere else, not fully
   Sylvain: And then we have the spec for the static definition of
            media queries
   Sylvain: And because we have different specs, we won't have a full
            set of testcases
   ChrisL: Sounds like you're arguing to merge the two specs
   Sylvain: ... interop
   ChrisL: There is a problem with testing things between the specs
   Sylvain: I think it's worth it, but I'd like to hear what others
            think. Because right now there is no interop
   <ChrisL> ... and thus these two should be combined
   Sylvain: The results at the edges are pretty strange
   dbaron: We discussed in the past what empty media queries should mean
   dbaron: We concluded that empty media queries are equivalent to all,
           but other specs might not allow empty media queries.
   dbaron: So you can't write @media { } and expect that to apply to all
   <ChrisL> why does that spec disallow an empty media query?
   <fantasai> because it wasn't allowed in 2.1
   dbaron: The spec has changed over time, and maybe some statements
           that would clarify have moved around or been lost
   Sylvain: For compat with legacy, you have media='' equivalent to
            all, and then @media { } is invalid, and then deleting
            mediums from the OM gives you 'not all'
   Sylvain: I think I understand what I'm supposed to do for a static
            style sheet, but I'm not so sure about the OM
   glazou: Does that mean we need an extra constraint on the OM saying
           that the empty media list is invalid for the OM?
   Sylvain: I don't think we'll get a perfect model for compat, but,
            even if the attribute, OM, and style sheet behave differently
            at least it should be defined somewhere
   ChrisL: Why can't @media { } mean all?
   dbaron: I think it's perfectly reasonable for it to mean all, but every
           time we discuss this issue we come to a different conclusion
   dbaron: We resolved last August that it should be invalid. I went and
           implemented that.
   dbaron: It's gotten to the point that when the group discusses something
           and resolves it, I don't consider it permanent
   <ChrisL> this is why we need to get specs to rec instead of being in
            permanent churn
   Sylvain: I'm not asking for consistency among OM, attr, and CSS, I just
            want it clearly defined
   glazou: If I have an @media string, and from the OM I want to remove
           the one media attached to it and replace it with anothe
   <ChrisL> i agree with daniel. the intermediate state is all
   glazou: It makes sense for the intermediate state to mean all
   <ChrisL> that isn't a contradiction. its ok to have something reachable
            by dom that is not reachable by syntax
   glazou: I see the parsing and the OM being independent
   dbaron: From an implementation perspective, there's a tricky issue here.
           Because the way the media query spec defines invalidity
   dbaron: An invalid query doesn't invalidate the list of queries, it only
           invalidates that particular query
   dbaron: And invalid queries are treated as false
   dbaron: You would need to record that there was some invalid thing
           that's false, so that when you remove the valid attributes
           you get false, not all
   glazou: If we say that an empty media list attached to the OM is
           equivalent to 'all' ...
   dbaron: The tricky thing is what is an empty media list
   dbaron: If you have an invalid media query as part of the media list,
           you have to keep track of that.
   dbaron: We implemented that the media query was not empty, and that's
           a permanent state: you can't remove everything through the OM
   dbaron thinks maybe he needs to write something up with examples
   glazou: Does this mean the error-handling rules of media queries make
           it impossible to handle a few cases
   <ChrisL> it sounds like the rules throw up an error state for no good
   glazou: It seems we may need to revisit the error-handling rules
   Sylvain: all is a sensical default for empty media lists
   peter: What happens if you then serialize the OM?
   Sylvain: Then you serialize as 'all'
   Sylvain: It's an edge case, but the spec should say something about it
   Sylvain: It would be nice to have it all in the sme place and have a
            suite of testcases
   dbaron: I think there's a relatively straightforward solution wrt
           error handling, and that's to replace any invalid queries
           with 'not all'.
   <dbaron> print, screen and (nonexistent-query), projection
   <dbaron> turns into
   <dbaron> print, not all, projection
   <dbaron> so that if somebody then does
   <dbaron> media.remove("print")
   <dbaron> media.remove("projection")
   <dbaron> you have 'not all'
   <dbaron> rather than an empty query that evaluates to 'all'
   Bert: Why wouldn't you just ignore it?
   fantasai and glazou try to explain why
   ACTION: dbaron and glazou Write a proposal
Meeting closed.
Received on Saturday, 1 May 2010 00:39:49 UTC

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