- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 30 Apr 2010 17:39:13 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- 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 ======
Present:
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
Calc()
------
<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?
-howcome
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_Atanassov
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?
no
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
defined
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
media
<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
reason
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