- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 26 Oct 2011 13:55:20 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Reviewed Tab's proposed note for unmaintained specs
- Discussed TPAC logistics, observers (probably all cannot fit)
- RESOLVED: Deferred cap-height unit proposal to level 4
- Discussed minimum ranges/precision for CSS values
- RESOLVED: Not moving value serialization into CSS3 Values and Units
- RESOLVED: Rename 'vm' as 'vmin'.
- RESOLVED: vh/vw/vm stay as percentages of viewport size; clarify spec
- RESOLVED: Move Stages of Value Computation section to CSS3 Cascade, and
update CSS3 Cascade and sync to 2.1 so that it's no longer
obsolete, just unmaintained.
====== Full minutes below ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Vincent Hardy
Koji Ishii
John Jansen
Brad Kemper
Peter Linss
Eric Mueller
Edward O'Connor
Anton Prowse
Florian Rivoal
Alan Stearns
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2011/10/26-css-irc
ScribeNick: fantasai
Administrative
--------------
glazou: Extra items?
TabAtkins: Would like quick yay/nay on proposed note for obsolescence of
old WDs
<TabAtkins> http://lists.w3.org/Archives/Member/w3c-css-wg/2011OctDec/0047.html
This specification is not being actively maintained, and must not be
used as a guide for implementations. It may be revived in the future,
but for now should be considered obsolete.
If you have questions or comments on this specification, please send
an email to the CSSWG's mailing list at www-style@w3.org.
fantasai proposed s/must/should/
<dbaron> In addition to the use of "should" and "must", I think you should
change "CSSWG" to "CSS Working Group"
Bert: Tab can add to the editors' drafts, but what about published drafts?
Tab: Should republish WD as well, possibly add a sentence or two
glazou: Add link to www-style
<glazou> http://lists.w3.org/Archives/Public/www-style/
Bert: Do we have a list of all the obsolete drafts?
Tab: I started a list in the thread, two emails asking for changes to
the list
Tab: Would go with that list amended
fantasai suggests putting the list on the wiki
<fantasai> http://wiki.csswg.org/spec
TPAC
----
glazou: Has everyone seen the details for the Sunday meeting at Adobe?
<glazou> http://wiki.csswg.org/planning/tpac-2011
vhardy: We're thinking of setting up dinner at 6:30pm in San Jose, that
sound ok?
glazou: Some people are vegetarian?
TabAtkins: Given Vincent's vegetarian, I'm sure he's handled that. :)
glazou: I will browse agenda items for TPAC tomorrow and try to schedule
things
Florian: There was on the W3C site a very long list of ppl who would
like to observe
glazou: I got some requests from Adobe for observers from Adobe
glazou: I also got some requests for other observers. I gave them rules
we gave the Japanese observers at Mozilla. We usually accept
all observers, as long as there is space.
Florian: The list on w3c site was O(tens)
<Bert> (We have 35 people signed for the meeting up as *member*, assuming
they all clicked the right button, we'll not have much room for
the 32 observers...)
<Bert> https://www.w3.org/2002/09/wbs/35125/TPAC2011/registrants
ACTION glazou: send an email to people who requested observer status
<trackbot> Created ACTION-373 - Send an email to people who requested
observer status [on Daniel Glazman - due 2011-11-02].
glazou: I notice a lot of ppl arriving Friday, could make dinner plans
for Friday night over email
glazou: anything else about TPAC?
vhardy: How are we arranging carpool?
fantasai: I'm just going to assign people to cars on Friday.
CSS3 Values and Units
---------------------
Issues list: http://www.w3.org/Style/CSS/Tracker/products/8
ISSUE-77 http://www.w3.org/Style/CSS/Tracker/issues/77
TabAtkins: Cap-height unit proposal from dbaron
http://lists.w3.org/Archives/Public/www-style/2008Nov/0552.html
fantasai: Question is add or don't add; should be similar to ex-height to
define
<Rossen> How is this going to impact the line height itelf?
Florian: What about Japanese text?
dbaron: The use case is fitting something on the baseline to be the size
of the letters
sylvaing: what kind of use case?
szilles: introducing new glyphs, e.g. for math
Florian: Not sure introducing one unit will be enough to solve the problem
TabAtkins: For Japanese, em-height should do it. For lowercase letters,
ex-height will do it
sylvaing: Is this common? Do people like Brad have to do this often and
have to hack it?
TabAtkins: If I'm putting a sparkline inline with the text, you don't
want it to be bigger than the text.
fantasai: Wouldn't that be em-height?
TabAtkins: Not if you want it baseline-aligned
sylvaing: Is it a height issue or baseline issue?
fantasai: The height you choose depends on the baseline you choose
TabAtkins: Right now, if you want something to extend from top to bottom
of the line, you set vertical-align to bottom and give it 1em
height
TabAtkins: You can make it ex-height and baseline-aligned to fit within
the lowercase area
TabAtkins: But you can't do baseline to top because we don't have this case
Florian: If we can solve all languages with one or two units, then it's
good, but if it's many new units for all scripts, then maybe
that doesn't work so well and we should use a different solution
szilles: The ratio of ascender to descender can vary between fonts. So
cap-height will be different for different fonts.
<stearns> there are a lot of font metrics we could expose - we may want
to defer doing this until we have the time/interest in exposing
it all
Florian: I think the idea is good if it extends to other scripts
sylvaing: And if the fonts support this data
some discussion of international considerations: ideographic, indic,
vertical-flow, thai
fantasai: So the plan is, afaict, to defer this to the next level
szilles: I'll ask font guys about metrics for things like sparklines
RESOLVED: Deferred to level 4
ISSUE-173 http://www.w3.org/Style/CSS/Tracker/issues/173
TabAtkins: next issue is required ranges for CSS
TabAtkins: Implementations must go at least up to this number; may go beyond
szilles: Didn't we resolve on this?
fantasai: We resolved to have this requirement, but not what it is
Florian: Let's assign action items to browser vendors to investigate
TabAtkins: I've never heard anyone complain about overflow, so whatever
we're doing now is fine.
arronei: I have most of the information/testcases for this
<glazou> we need a test case for z-index for the max
arronei: new properties would be tricky if they're different
<Bert> (Range? Or precision?)
fantasai: Can you make a proposal for what to put in Values and Units?
arronei: I can collect the data
Bert: I wonder if this is 2 different things. Range - do we accept 10km?
But also precision. Do we handle 1 part in 1000?
ACTION arronei: collect data and make a proposal
TabAtkins: I know Opera goes under 2^31 on some things
Rossen: If something like this goes into the spec, it should be on the
lower bounds so that we don't have to go fix anything depending
on the type
Florian: Why are we doing this?
TabAtkins: For the test suites, we need to know what's a valid range to test
TabAtkins: Right now we could know implementations support up to .. 8
but nothing beyond that.
TabAtkins: It's primarily a quality-of-implementation issue, but want some
minimum to meet or exceed
Florian: It's not intended to be an exercise where we have to change the
implementations, right?
Right.
ISSUE-186 http://www.w3.org/Style/CSS/Tracker/issues/186
TabAtkins: proposal to move CSSOM value serialization from CSSOM to
CSS3 Values
dbaron: That's moving them from a less stable spec to a more stable spec
dbaron: I'd like to review them carefully... may not have gotten a lot of
atttention yet.
fantasai: Question here is, do we even want to move them
glazou: Seems like a Pandora's box
glazou: Would want to add serialization to all the other CSS constructs
glazou: Also, might be useful to implementers to have it all in one place
fantasai: Could be a separate, parallel module, e.g. CSSOM Values and Units
sylvaing: or just have Serialization be its own thing
sylvaing: I think if you want to move Values and Units forward, doesn't
seem like a good idea.
sylvaing: I think having a single core Serialization spec would be a good
idea
glazou: I'd like time to investigate that.
glazou: I think we should leave it in CSSOM spec for now, and decide later
when we know better what needs to be split out and dispatch to the
various modules.
glazou: It's a lot of work.
fantasai: So close this issue no change?
glazou: That's my recommendation.
RESOLVED: Closed no change
* dbaron Zakim, who is noisy?
* Zakim dbaron, listening for 10 seconds I heard sound from the following:
glazou (69%), Bert (4%), tabatkins_ (20%)
* sylvaing 69% of the noise is produced by one person #OccupyGlazou
<glazou> ROFL
ISSUE-190 http://www.w3.org/Style/CSS/Tracker/issues/190
Removing or renaming 'vm' unit
sylvaing: There is one implementation, but at this point no clue on how ...
fantasai: I'm strongly in favor of renaming, b/c I think it's vague and
ambiguous and confusing.
Florian: The objection was based on most units being 2 letters
TabAtkins: We already have 3-letter units, so ehh.
arronei: Have an implementation, but not a strong objection.
TabAtkins: Should've prefixed it!
arronei: That's why it's not a strong objection. :)
RESOLVED: Rename 'vm' as 'vmin'.
Florian: Should we keep it at-risk?
fantasai: Could do, but I doubt someone implementing 'vh' and 'vw' would
skip it: it's trivial once you have those.
fantasai: So we could keep it at-risk, but that won't really mean much.
ISSUE-194 http://www.w3.org/Style/CSS/Tracker/issues/194
http://lists.w3.org/Archives/Public/www-style/2011Oct/0464.html
Florian: ppl are confused about whether it's 1/100th or just 1x
Florian: Do we want to change that?
fantasai: I think part of the problem is the spec was not very clear in
tying these to the idea of percentages, which make the 1/100th
factor seem less arbitrary.
fantasai: Also, since IE has an implementation: chances are vh and vw
are more used than vm, also this would be an interpretation
difference, which is more of a problem; vm -> vmin would just
trigger a parse error
fantasai: So I'm leaning towards not changing it
RESOLVED: vh/vw/vm stay as percentages, clarify spec
ISSUE-192 http://www.w3.org/Style/CSS/Tracker/issues/192
Move "Stages of Value Computation" spec to CSS3 Cascade
glazou: what means "mostly" in 2.1?
glazou: what's missing?
fantasai: Only examples afaict
glazou: I'm ok to move it if CSS3 Cascade is not marked as obsolete
fantasai: Ok, I'm willing to work with that conditional. Does anyone else
have an opinion?
dbaron: If someone starts fixing them up, shouldn't be marked obsolete
szilles: mark it unmaintained, not obsolete
Florian: Would need the spec to have an editor
TabAtkins: Doesn't need one if it's identical to 2.1
fantasai: So if we update CSS3 Cascade and sync it to 2.1 and post a WD,
and then leave it there without taking to LC because there's
nothing new or useful in it, is that ok?
florian: Why not move it along the rec track?
TabAtkins: Editors' time better spent elsewhere
glazou: And test suite is work
* sylvaing we need more editors...
RESOLVED: Move this section to CSS3 Cascade, update CSS3 Cascade and sync
to 2.1 so that it's unmaintained but not obsolete, and when
someone has a reason to move it forward along the rec track
(i.e. someething to put in it that's not already in 2.1) then
they can move it forward from there.
Meeting closed.
Received on Wednesday, 26 October 2011 20:56:02 UTC