See also: IRC log
<glazou> jdaggett: you're not attending the call, correct?
<bradk> Zakim aabb is me
<glazou> regrets from molly, TabAtkins, dsinger
<glazou> called dropped hold on
Zakim +47 is howcome
<scribe> ScribeNick: fantasai
<glazou> I have major phone issues apparently
Daniel: Peter and I would like to know where we are at this point
arron: I started work on adding
the metadata
... I should have half done by the end of this week, hopefully
all done by end of next week
... 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
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
... Question of what properties should apply to ::slot()
... Tab favors all properties, I prefer limiting the
properties
RESOLUTION: 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
... We haven't figured out what to do with things that are
dimensionally invalid for the property
... I suggest percentages transformed the same way they they're
handled in the property
... And all lengths converted to an absolute length
... If we add keywords, they would be treated similar to
percentages
... So if you say calc(50% + 2em)
... Then the em gets converted using the element's font
size
... 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%
... 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.
<glazou> dbaron: with fantasai
<div class="a"> <div class="b"></div> </div>
Say .a { width: 50% } resolves to 100px
You're suggesting that
You're saying b should resolve to 101px
rather than 26px
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
... So ems, you resolve the ems, and then inherit the
value
... Percentage values inherit all the way down as
percentages
Rossen; so percentages are resolved in your current space
Rossen: That makes sense to
me
... If you have calc(50%) it inherits down as 50 percent
... But calc(1em) inherits down as whatever 1em calculates tow
here it's specified
... 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.
... This is already an issue. calc() makes it more complicated
because some values computed and others don't
... so it emphasizes the problem
... 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.
... 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.
<dbaron> What's the difference between these proposals?
glazou asserts that dbaron and fantasai and Rossen and sylvain have different proposals
dbaron and fantasai don't understnad why
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
... 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.
<bradk> width: calc(100% - <padding-amount>) is something I could imagine using, and inheriting
glazou: Is anne on the call?
<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
<glazou> http://lists.w3.org/Archives/Public/www-style/2010Apr/0391.html
Sylvain: The one thing was the
definitions are in two different places
... 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
... Right now we have the OM defined somewhere else, not fully
defined
... And then we have the spec for the static definition of
media queries
... 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
... We concluded that empty media queries are equivalent to
all, but other specs might not allow empty media queries.
... So you can't write @media { } and expect that to apply to
all media
<ChrisL> why does that spec dissalow an empty media query?
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'
... 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, but every time we discuss this issue we come to a
different conclusion
... We resolved last August that it should be invalid. I went
and implemented that.
<ChrisL> this is why we need to get specs to rec instead of being in permanent churn
dbaron: It's gotten to the point that when the group discusses something and resolves it, I don't consider it permanent
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
... An invalid query doesn't invalidate the list of queries, it
only invalidates that particular query
... And invalid queries are treated as false
... 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
... If you have an invalid media query as part of the media
list, you have to keep track of that.
... 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'
... It's an edge case, but the spec should say something about
it
... 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
<scribe> ACTION: dbaron and glazou Write a proposal [recorded in http://www.w3.org/2010/04/28-CSS-minutes.html#action01]
<trackbot> Created ACTION-226 - And glazou Write a proposal [on David Baron - due 2010-05-05].
Meeting closed.
<glazou> szilles: still here ?
<glazou> apparently not
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/?/glazou/ Found ScribeNick: fantasai Inferring Scribes: fantasai Default Present: +95089aaaa, glazou, plinss, SteveZ, +1.650.275.aabb, bradk, Bert, arronei, sylvaing, smfr, +34.60.940.aacc, CesarAcebal, +47.21.65.aadd, fantasai, howcome, David_Baron, ChrisL, Rossen_Atanassov Present: +95089aaaa glazou plinss SteveZ +1.650.275.aabb bradk Bert arronei sylvaing smfr +34.60.940.aacc CesarAcebal +47.21.65.aadd fantasai howcome David_Baron ChrisL Rossen_Atanassov WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 28 Apr 2010 Guessing minutes URL: http://www.w3.org/2010/04/28-CSS-minutes.html People with action items: dbaron WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]