- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Thu, 13 Oct 2011 18:57:09 +0000
- To: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
One precision: Regarding the CSSOM discussion, we did resolve to base the CSSRule types in CSSOM on http://wiki.csswg.org/spec/cssom-constants pending the design of a more stable string-based API. We agreed to include css-device-adapt (@viewport) in the current constant table. > -----Original Message----- > From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf > Of fantasai > Sent: Thursday, October 13, 2011 10:33 AM > To: www-style@w3.org > Subject: [CSSWG] Minutes and Resolutions 2011-10-12 > > Summary: > - Discussed TPAC and Paris F2F logistics. Paris F2F will be at INRIA. > - RESOLVED: Monday 5pm Web Fonts joint meeting at TPAC > - RESOLVED: Tuesday meeting for EPUB > - Gradients issue to be resolved at TPAC; wiki pages summary to be > created in the meantime <http://wiki.csswg.org/ideas/radial- > gradients> > - RESOLVED: Accept default type of attr() as string, not implied > - Discussion of moving to string constants instead of numeric for at- > rules > in CSSOM; to be continued at TPAC. > - RESOLVED: Add Paul Irish's suggested @supports API to css3- > conditional > - RESOLVED: WG backs Daniel Weck's decision to defer feature request > for > explicit language selection in CSS3 Speech to later version > - RESOLVED: Fix wording in CSS2.1 sections 6.2.1 and 6.1.1 to say that > 'inherit' causes the property's specified value to be its > parent's computed value. > http://www.w3.org/Bugs/Public/show_bug.cgi?id=14420 > - Discussed dropping 'vm' unit or renaming it to 'vmin'. > > ====== Full minutes below ====== > > Present: > César Acebal > Tab Atkins > David Baron > Kimberley Blessing > Bert Bos > Brady Duga > Arron Eicholz > Elika Etemad > Simon Fraser > Sylvain Galineau > Daniel Glazman > Arno Gourdol > Molly Holzschlag > John Jansen > Brad Kemper > Hĺkon Wium Lie > Chris Lilley > Divya Manian > Alex Mogilevsky > Edward O'Connor > Florian Rivoal > Alan Stearns > Daniel Weck > Steve Zilles > > <RRSAgent> logging to http://www.w3.org/2011/10/12-css-irc > <bradk> Zakim, aajj is me > > Administrative > -------------- > > bradk: wants to discuss epub discussion at TPAC > TabAtkins: wants to talk about inherit value in 2.1 > fantasai: discuss values and units > howcome: on Opera's implementation of GCPM > > glazou: aboutf2f in paris > glazou: there are 26 or 27 people registered which is a lot > glazou: 1st choice has max attendance of 24 so its not feasible > glazou: w3c office in paris suggests we can have 2 meeting rooms. conf > from 6th - 8th of Feb. It is in downtown, 14 mins from subway > station > * ChrisL there are good restaurants nearby in Rue de la Buttes aux > Cailles > <dbaron> I added the map link to http://wiki.csswg.org/planning/paris- > 2012 > (and also the dates). > glazou: I will send list of hotels asap > <dbaron> http://wiki.csswg.org/planning/paris-2012 > > TPAC > ---- > > <glazou> > http://www.w3.org/mid/7534F85A589E654EB1E44E5CFDC19E3D0C29DDAE47@wob- > email-01.agfamonotype.org > glazou: 2 reqs joint meeting with webfonts wg > ??: webfonts is not meeting at tpac but some members will be there. > glazou: ChrisL will be part of joint meeting on behalf of webfonts WG > ChrisL: I don't have a preferred time. 4 or 5people might be there. > ChrisL: the discussion topic is part of css3 fonts > ChrisL: rather than be specific for WOFF rather than font face for all > formats > glazou: will john daggett attend TPAC? > dbaron: I suspect he is, I am not sure. > glazou: when is the best time to have meeting for japanese people in > santa clara > dbaron: 5pm in CA is 9am in Japan > <dbaron> or something, depending on sommer time > RESOLVED: Monday 5pm Web fonts joint meeting > Brady: can only attend for one day. preference tuesday. > RESOLVED: Tuesday meeting for e-pub > glazou: add items to the agenda > <dbaron> http://wiki.csswg.org/planning/tpac-2011 > > mollydotcom: is there some activity on sunday? > glazou: its a day of meeting for CSSWG > glazou: bert do we have a room > Bert: doubt it. I have not heard from orgn. Better to look for another > place. > glazou: who can host meeting on sunday > fantasai: I'm pretty sure mozilla can host > mollydotcom: we could also ask stanford. > Arno: we can host in San jose @ Adobe > glazou: san jose seems closest. > arno: will check it out and get an official answer this week. > ChrisL: step out on monday 11-12 > <sylvaing> I would also step out with ChrisL > > glazou: is there some overlap with AC meeting during days of CSS WG > meeting. > Florian: I am not but don't think so. > glazou: if there is, he is not sure he is able to attend TPAC as he is > sick. > glazou: if I am the only one chairing I will have a problem > Florian: there are AC meetings on tuesday > Florian: there is AC exec session for AC chairs > glazou: we will find a solutionn and I will discuss with ChrisL and > Brady > via email > <dbaron> https://www.w3.org/2011/11/TPAC/ac-agenda has AC starting at > 2pm Tuesday > <ChrisL> attendees list for CSS WG at TPAC > http://www.w3.org/2002/09/wbs/35125/TPAC2011/registrants#css > > Gradients > --------- > > glazou: like to have an update. > TabAtkins: suggest we do what fantasai suggested: create a summary and > defer final decision until TPAC, then make quick decision > and go to last call. > ChrisL: I think it's a good plan > glazou: requesting everyone interested in gradients reads it and is > ready > before the joint TPAC > TabAtkins: will alert when I got something that is not a placeholder > glazou: how long do you need at TPAC? > <fantasai> http://wiki.csswg.org/ideas/radial-gradients > TabAtkins: we need 20 to 30 mins > Florian: for such a heated topic? > <smfr> 8 hours! > arronei: an hour > glazou: TabAtkins can you add to TPAC wiki page > > CSS3 Values: Implied types and attr() annotation > ------------------------------------------------ > <glazou> http://www.w3.org/mid/CAAWBYDDasgHLxCjTk0gC- > Qy_kmrt+Q_DqcuaukEB58d7=Dd8Pg@mail.gmail.com > TabAtkins: minor issues > TabAtkins: there is an issue in spec for implied types, wondering if we > can > have attr() default to that type rather than string. > TabAtkins: me and fantasai don't think its workable. If we change one a > property to accept other types, it will break uses of attr > in > the wild > howcome: by dropping issue you require type to be specified always? > TabAtkins: default to string > howcome: issue comes up when you have width = 200 and you want width to > be pixels > TabAtkins: it's not ideal. > glazou: does it have more downsides than upsides I don't think it's the > case. > howcome: if its a number its unlikely that you want it to be a string > fantasai: then you need to parse to make sure its a number > fantasai: if you want width to be pixels then you need to specify as > pixels > otherwise it would be a string. > fantasai: you need to specify the unit in any case > howcome: wondering if there is something else smart we can do and save > people typing 3 chars > glazou: howcome do you want to take an action item? > howcome: I don't think I will create a counter proposal > TabAtkins: The alternative is to allow properties to define default > attr() > types for themselves but seems like a lot of overhead. > TabAtkins: auto inference is not possible. > howcome: if it has to be a default is string the best? > TabAtkins: string requires no parsing and cannot fail > TabAtkins: and for legacy reasons it is already required to be a > string: > CSS2.1 'content' accepts attr() with no type specifier > glazou: accept this for time being and then if we find something > smarter > we use that > RESOLVED: accept default type of attr() as string, not implied > > CSSOM > ----- > > Topic: Question from sylvaing about new stuff in CSS OM > <glazou> > http://www.w3.org/mid/3C4041FF83E1E04A986B6DC50F01782938A101@TK5EX14MBXC29 > 7.redmond.corp.microsoft.com > sylvaing: everytime we add a new @ rule we need a new constant in css4 > for > a new rule type > sylvaing: how do you define them without creating conflicts, need a > branch > for prefixed version. > <dbaron> we have a wiki page now, at least! > sylvaing: one for viewport rule for e.g. brittle mechanism so what do > we > do next? > TabAtkins: we can continue same way with numeric constant and > standardize > on wiki page. Wiki is normative definition for numeric > consts. > do same for ranges for vendor prefix constants > TabAtkins: or switch over to string. > dbaron: I don't think memory aspect of string is something to worry > about. > dbaron: good practice for api design is to use strings rather than > constants. > sylvaing: we should agree on a cut off point. > TabAtkins: agreed. > glazou: is this something to forward to annevk? > TabAtkins: ya > <dbaron> if we add a new string api, we could make all the things that > don't > get constants report UNKNOWN_RULE as the constant, or > something > like that. > glazou: will it be a 20-30 min discussion at TPAC? > sylvaing: we should tidy up and assign constants. > dbaron: anne created a wiki page for the constants > glazou: we will discuss what we do at TPAC > <dbaron> http://wiki.csswg.org/spec/cssom-constants > sylvaing: wondering for W3C reffing a wikipage anyone can edit is that > scary > glazou: are you sure about that? > TabAtkins: only those with wiki accounts possibly the testers > fantasai: we have ACLs for wiki, easy to restrict this page to wg > ChrisL: we have complete changelog so malicious changes can be rolled > back > mollydotcom: assuming wiki is not that . in a secure way > fantasai: right now entire wiki is publicly readable > TabAtkins: restrict writing to WG members > glazou: readable by public and writable only by working group members > fantasai: which page. > glazou: the url dbaron pasted > glazou: need to add viewport rule to that list > <mollydotcom> that's what I've been doing > glazou: sylvaing edit wikipage for TPAC and add discussion > <mollydotcom> Sylvain: no need, just got it there > <mollydotcom> well, the discussion - I'm adding the URL > <glazou> http://www.w3.org/mid/CAHSVx=8sOOh=5Wr2cv4eUhT8AzWTdnPybpFF- > WR5ujEqEESwiA@mail.gmail.com > <fantasai> cssom-constants is already locked down as edit only for > css-wg members and a group made for other trusted members > > @supports API > ------------- > > Topic: request from paul_irish on css3 conditional > glazou: dbaron I think you commented on that. > glazou: adding an api matching > TabAtkins: I don't think much needs to be discussed. dbaron seemed > agreeable > to adding that > glazou: everyone agrees on that? > <dbaron> http://lists.w3.org/Archives/Public/www- > style/2011Oct/0323.html > whats the resolution? > RESOLVED: add paul irish's suggested api to the spec > > LC for css3-speech > ------------------ > > <danielweck> http://wiki.csswg.org/spec/css3-speech > danielweck: Currently 18 issues filed. cant go thro each. > danielweck: WG needs to reach consensus on each of these issues. When > we > accept suggested change in spec, whats the next step? > glazou: let the commenter know that you addressed the comments, say > something about the resolution. that person needs to accept or > reject your resolution of the problem > danielweck: what about bigger issues? potential blocker language > selection > features for TTS voice. > danielweck: irrespective of nature of markup. > danielweck: would be a new feature, if we were to accept to introduce > the > new feature, we mark it at-risk and we republish another > LC? > ChrisL: yes > glazou: or you can reject the feature and say you will consider for > future > version > fantasai: if there is an issue where you and commenter is not agreeing, > escalate to WG either we make the change or reject. that > becomes > the official WG response, they either accept or formally > object. > it will get recorded in the list of issues and presented to > director. > fantasai: we can go to LC even when a commenter disagrees with us > danielweck: paul bagshaw co-author of SSML > danielweck: it was one of the major changes of 1.0 to 1.1 of SSML(?) > danielweck: the abstract of css3 speech states that ssml 1.1 model it > implies it follows to letter, it is more flexible goal > ChrisL: which of these options do you want to do? > danielweck: I would rather stick to our guns > danielweck: forcing the implementers to convey a set of info about tts > voices to styling engine > danielweck: risk it will be implemented badly and much normative stuff > needs > to be added to spec if it needs to work > glazou: reasonable to reject and kind of argument we can show to dir. > ChrisL: do we have a WG resolution to back that? > danielweck: eventually perhaps next week we should go through the > issues > and record the WG consensus > danielweck: I am happy to work through this one now. > glazou: sounds perfect > fantasai: make sure you end every response with "please let us know if > this satisfies your concern" > danielweck: totally > glazou: the FPWG sent comments late and you still added them for > official > list of issues for last call > glazou: you have an option to reject them coz its too late. > fantasai: they got an extension > glazou: it arrived only 1 or 2 days ago > danielweck: Many of their issues argue that the features in CSS Speech > hijack the screen-reader experience, which is.. > interesting. > danielweck: I think we need to clarify that > RESOLVED: WG backs danielweck's decision to reject issue-2 for this > level > <fantasai> http://wiki.csswg.org/spec/css3-speech#issue-2 > ChrisL: are you clear on next steps danielweck? > 11:46 -!- glazou [glazou@82.247.96.19] has quit [Quit: running] > danielweck: I hope you can take a look at the issues next week so we > can > make informed decision > ChrisL: listing of issues and then look at commenters disagreed on > resolution. > <fantasai> danielweck, just let me know when you're done with the DoC > in > the wiki and I'll convert and colorize it for you > <danielweck> Thanks Fantasai! > > CSS2.1 'inherit' value > ---------------------- > > <ChrisL> tab 2.1 inherit > http://www.w3.org/Bugs/Public/show_bug.cgi?id=14420 > TabAtkins: address issue on inital value in draft > TabAtkins: originally 2.1 said inherit computed to computed value of > its > parents > TabAtkins: currently: if cascaded value is inherit specified value = > specified > value of parent. both wrong > dbaron: currently sez is ambiguous > TabAtkins: if cascade value is inherit, specified value is computed > value. > Florian: what is specified value > TabAtkins: specified value is pre-any-transformation any value > <sylvaing> thought specified was the value written by the author in > their > stylesheet > dbaron: whats not clear to me is why specified value isn't just inherit > <ChrisL> if the parent value is also inherit? > TabAtkins: 1. not how normal inheritance works, inheritance takes the > computed value of the parent as the specified value on > the > child > 2. issues with inherit being a specified value and spec > wording > referring to specified values, maybe not a problem in > practice. > TabAtkins: consistency with real inheritance. > <oyvind> seems like there's some duplication in 6.2.1 vs 6.1.1... > ChrisL: I don't hear anyone expressing much of an opinion. are people > comfortable with the change. it would be an errata. > TabAtkins: it would also change values & units > dbaron: change in 6.1.1 and 6.2.1 > TabAtkins: both needs to be changed > <fantasai> The spec generally assumes that the specified value resolves > to > a real value, and says "if the specified value is foo, do > ..." > in many places > TabAtkins: we will resolve inherit and initial at that point. > howcome: This is consistent with css3 cascade module > * sylvaing was completely wrong about specified values, as it turns > out.... > <oyvind> sylvaing, I think it changed after > http://lists.w3.org/Archives/Public/www- > style/2011Mar/0507.html > RESOLVED: accept TabAtkins and fantasai's proposal to word spec such > that > inherit turns the specified value into the parent's computed > value > > CSS3 Values and Units > --------------------- > > <ChrisL> fantasai/tab CSS 3 V@U issues > http://www.w3.org/Style/CSS/Tracker/products/8 > fantasai: vm unit is really a v min unit: min of vh and vw > fantasai: since we have a min f() we can remove it. > fantasai: alt we can rename it to vmin > fantasai: it's not clear what it is > dbaron: concerned coz min() is at risk and likely to get dropped > TabAtkins: at minimum we should rename to vmin. We can mark it as at- > risk > and at our at-risk notes one or the other should be dropped > howcome: : why don't we continue to have 2char units > fantasai: I don't think its worth the confusion > fantasai: Could stand for vmin or vmax > TabAtkins: or vmean :) > ChrisL: is that a strong obj > howcome: going to 4 is suddenly outside of tradition > ChrisL: in this case there is a motivation for the change as its > ambiguous > fantasai: vmin makes it very obv to person reading the stylesheet > TabAtkins: salvage min() it would be preferable > bradk: are there places where you can use unit can't use min > TabAtkins: calc should be usable anywhere that expects a length > (min/max too) > bradk: even with 4 char it's more compact than using min > mollydotcom: does not have an opinion at this point. > mollydotcom: vmin on its own make more sense > <fantasai> 5vmin == min(5vh, 5vw) > arronei: IE already implements vm > TabAtkins: we can see if there is any use in the wild of those > TabAtkins: not sure what the usecase of vmin > howcome: make sure your image does not get out of the viewport? > <fantasai> howcome, use max-height: 100vh; max-width: 100vw; > mollydotcom: can't imagine a usecase > bradk: no vmax to ensure complete coverage? > ChrisL: cant get to your topic howcome is it okay to do it on next call > ChrisL: lets take it to email. > ChrisL: call adjourned! > * Bert thinks v_min with "min" in small font and lowered a bit > * dbaron thinks Bert's idea would be v_{min} :-) > > <dbaron> TabAtkins, someday I should sit down with you and explain how > hard min() and max() are... > <mollydotcom> dbaron: I'd like to understand > <mollydotcom> dbaron: I think it would make a fascinating article for > devs > <ChrisL> I would be interested also,conceptually min and max functions > seems simple > <Ms2ger> ChrisL, like floats? :) > <ChrisL> like IEEE floats with scientific notation. dead simple > <sylvaing> they seem simple, but how often do you nest them in a tree > and > then resolve them ? > <ChrisL> so it needs a rootwards tree walk to resolve? > <sylvaing> rootwards sounds like a dental procedure > <ChrisL> is there an issue with circularity? > <dbaron> no, the problem is that many times percentage widths are used > in > computations in manners other than "take the input and > multiply it > by the percentage" > <dbaron> one of the problems, anyway > <mollydotcom> can you give a simple example? > <dbaron> I believe calc() with min() and max() allows all piecewise- > linear > continuous functions from percentage-basis to result, which > makes > things pretty messy. > <dbaron> An example would be: > <dbaron> <table><tr><td style="width: 25%"><div > style="width:100px"></div></td> > <td>second cell</td></tr></table> > <dbaron> the table ends up 400px wide > <mollydotcom> is there another width somewhere on the table? > <mollydotcom> this is where I'm confused. > <mollydotcom> 25% of what is my question. > <sylvaing> mollydotcom, no. content of the first cell is 100px, but > because > it's also 25% of the total you end up with a 400px table > <mollydotcom> ah okay, took me a minute > <mollydotcom> ;) > > <dbaron> fantasai, so given that everybody seems to forget about the > 1/100 > factor for vh/vw/vm, I really wonder if we shouldn't have the > 1/100 factor... > <nimbupani1> +1 >
Received on Thursday, 13 October 2011 18:57:39 UTC