W3C home > Mailing lists > Public > www-style@w3.org > October 2011

RE: [CSSWG] Minutes and Resolutions 2011-10-12

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>
Message-ID: <3C4041FF83E1E04A986B6DC50F01782938CDCC@TK5EX14MBXC297.redmond.corp.microsoft.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:45 GMT