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

[CSSWG] Minutes and Resolutions 2011-10-12

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 13 Oct 2011 10:33:23 -0700
Message-ID: <4E9720E3.1020808@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
   - 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.
   - Discussed dropping 'vm' unit or renaming it to 'vmin'.

====== Full minutes below ======

   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


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


   <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


   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


   Topic: Question from sylvaing about new stuff in CSS OM
   <glazou> http://www.w3.org/mid/3C4041FF83E1E04A986B6DC50F01782938A101@TK5EX14MBXC297.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
   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@] 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
   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
   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
              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
   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
   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 17:33:53 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:05 UTC