- 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