W3C

- DRAFT -

SV_MEETING_TITLE

28 Apr 2010

See also: IRC log

Attendees

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
Regrets
Chair
SV_MEETING_CHAIR
Scribe
fantasai

Contents


<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

Test Suite

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

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
... Question of what properties should apply to ::slot()
... Tab favors all properties, I prefer limiting the properties

RESOLUTION: 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
... 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>


.a { padding: really big; }

Say .a { width: 50% } resolves to 100px


.b { width: 50%; } resolves to 25px
.b { width: inherit; } currently also resolves to 25px

You're suggesting that


.a { width: calc(50% + 1px) } (resolves to 101px)
.b { width: inherit; }

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.

Selectors Serialization

<bradk> width: calc(100% - <padding-amount>) is something I could imagine using, and inheriting

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
... 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

Summary of Action Items

[NEW] ACTION: dbaron and glazou Write a proposal [recorded in http://www.w3.org/2010/04/28-CSS-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/04/28 17:59:49 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]