- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 13 Oct 2011 10:33:23 -0700
- To: "www-style@w3.org" <www-style@w3.org>
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@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
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 17:33:53 UTC