- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 11 May 2011 11:18:26 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- We're missing AC reviews for CSS2.1. Reviews have been
submitted by MS, Mozilla, Opera, Nokia, and Apple. All
other W3C Members should ping their AC reps to send in
a review.
https://www.w3.org/2002/09/wbs/33280/css21pr/results
- RESOLVED: Use plinss's spec annotation system for CSS2.1
and future specs. (It annotates sections of the
spec with test results and a link to the tests.)
- RESOLVED: Define cjk longhand list numbering up to 100,000
with fallback to cjk-decimal beyond, allow UAs to
implement longhand beyond that limit, put definition
for that in informative appendix.
- RESOLVED: Add new CSS3 width keywords as an appendix to CSS3
Writing Modes, add note that they might be moved/copied
to a more appropriate spec later.
- Adobe plans to request FPWD for CSS Regions next week.
====== Full minutes below ======
Present:
César Acebal
Tab Atkins
Bert Bos
Cathy Chan
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Arno Gourdol
Koji Ishii
John Jansen
Brad Kemper
Peter Linss
Edward O'Connor
David Singer (via IRC)
Daniel Weck
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2011/05/11-css-irc
ScribeNick: fantasai
Administrative
--------------
plinss: Any other items for the agenda?
szilles: WD status for regions?
plinss: Kyoto F2F, need agenda items
plinss: Add them earlier so people have time to review and prepare
http://wiki.csswg.org/planning/japan-2011
plinss: Bert sent a message that we're missing reviews for CSS2.1
TabAtkins: Is there a way to see who has sent in a review?
<plinss> https://www.w3.org/2002/09/wbs/33280/css21pr/results
plinss: MS, Mozilla, Opera, Nokia, and Apple have responded
plinss: Chris is missing, can't talk about charter
plinss: Is Bert here to talk about website?
plinss: Nope.
Spec Annotation System
----------------------
plinss: Next is spec annotation system
which annotates the spec with test results
plinss: Just wanted to get some quick input, discussed on email
plinss: Do we want to add this to CSS2.1? Do we want to use moving forward?
TabAtkins: Would def like to use for specs I edit
szilles: +1
<sylvaing> +1 as well
arronei: Would like for 2.1 and any in the future if possible
plinss: Any objection to adding to CSs2.1?
CJK longhand styles
-------------------
<plinss> http://lists.w3.org/Archives/Public/www-style/2011Apr/0764.html
TabAtkins: Some ppl objected to complexity in lists
TabAtkins: The only complex parts I could potentially remove are the
special styles like CJK ones
TabAtkins: They were defined up to 10^16, which is way more than any
impl can do
TabAtkins: If I limit range to 10^4 I can represent Japanese and Korean
styles as additive style
TabAtkins: And Chinese becomes much simpler
TabAtkins: I think 10,000 is a reasonable limit here.
TabAtkins: I wanted to know if anyone wants CJK longhand styles to go beyond
arronei: I think your limit is reasonable, but I don't think it should
be a hard limit.
arronei: If a UA wants to go beyond then it should be able to do that.
TabAtkins: When you exceed the range, you drop to a fallback style
TabAtkins: In this case, drops to cjk-decimal
bradk: Can't we say that if the UA supports the larger numbers, then
they should do it in the more sophisticated way?
TabAtkins: If I'm not specifying it
TabAtkins: I either specify a larger range or a shorter range
sylvaing: So once the fallback comes, can you get the proper numbers
by more rules?
sylvaing: by specifying ... [????]
TabAtkins: theoretically
TabAtkins: Officially, I could go up to 10^5 and still have all the
same benefits, it's just 10^6 Japanese and Korean can't be
additive, and Chinese gets more complex
sylvaing: I would rather have the spec be clear
TabAtkins: There are other number systems already in the spec that have
similar problems.
TabAtkins: Hebrew, frex, has ways of expressing numbers beyond the range
in the spec right now.
sylvaing: The use case isn't representing all numbers
TabAtkins: I could potentially go through and identify all the types of
lists that have longer representations than I've defined
TabAtkins: Like circled decimal type, only has 50 Unicode chars. You
could always synthesize more
TabAtkins: But I don't want to make things vague.
TabAtkins: Going through and explaining how to extend them would be
more complexity than people want
bradk: You were talking about putting those in an appendix
TabAtkins: The definitions are part of the spec in an appendix for ua
stylesheet
bradk: If you wanted to go beyond 10,000 you could still recommend what
the UA puts in its style sheet
TabAtkins: If I carve out an exception for CJK longhand
TabAtkins: That's inconsistent
TabAtkins: We do know how to do it correctly, but nobody wanted to do that.
fantasai: Not true. Webkit implements it (though buggy) and Mozilla
implements it correctly up to its internal counter limit
bradk: Even if there were some exceptions for e.g. cjk-longhand, I
think there'd be some value to have an exception for UAs that
want beyond 10,000
bradk: Some UAs in todays world have a problem going beyond such large
numbers, but at some point other UAs won't mind
TabAtkins: So at that point we'll require larger limits
?: ... that don't want those limits
TabAtkins: Hardware limits always override anything the spec says
fantasai proposes a straw poll
1) Define cjk counter styles up to 10^16 (full definition)
2) Define them up to 10,000 (artificially limited to simplify)
3) Allow both behaviors
TabAtkins: Note, the full definition is up to 10^68, but usually beyond
that you switch to scientific notation
fantasai: But we have a definition for up to 10^16 that we're pretty
sure is correct
TabAtkins: Everybody does counters up to 2^30, some go up to 2^31
TabAtkins: That's like 10^12
TabAtkins: There are only two complex styles left. Ethiopic-numeric
and cjk longhand
sylvaing: It's complex for no use case, why would you have such a long list?
TabAtkins: Most styles defined to infinity, note
bradk: Web is a big place. I'm not sure there aren't lists that go
beyond 10,000 or that start at 10,000 and go to 20,000
TabAtkins: There are other types defined up to infinity
TabAtkins: If I define the CJK styles out more fully, I'll want to
define the other styles more fully
TabAtkins: to be more consistent
Arno: 10,000 seems like a reasonable artificial limit especially if we
define the fallback for what happens if we go beyond that
plinss: I do think 10,000 items in the list is a reasonable limit, but
I'm concerned about lists that don't start counting at 1
sylvaing: Maybe the use case is someone who has a paged view of a database
sylvaing: You start at 12,000 one a particular page
TabAtkins: Printouts like that are the only really strong use case for
lists that start at large numbers, and you won't use cjk
longhand for that
glazou: Use case is email. You can have thousands of email in a list
TabAtkins: are you going to use CJK numbers for that?
glazou: why not
TabAtkins: longhand CJK is like writing out "one hundred" in English
fantasai: No, it's not. It's used in much more contexts than that.
TabAtkins: Note that 10,000 and beyond will have a lot of characters,
you have around two chars per digit
glazou: 10,000 is fairly common. 100,000 is more reasonable.
TabAtkins: I can go to 100,000 and keep things simple as they are
glazou: I think that drastically reduces the risk of problems in the future
sylvaing: ... the use case for high numbers is when you start at a very
high number
sylvaing: e.g. a paginated view of database results
TabAtkins: Is it use case enough that we define how to work those things?
<dsinger> as I said before, we can define conformance out to some reasonable
finite limit. well, we have to.
<dsinger> and then if the definition of how to go higher is referenced or
provided, UAs are welcome to knock themselves out
fantasai: So we could spend the rest of the call talking about databases,
or we could resolve on what to do
1) Define cjk counter up to 10^16 (full definition that we have ready to
go, more than counter hardware limits in place now)
2) Definte them up to 10,000
3) Definte them up to 100,000
4) Put both definitions in the spec, allow UA to implement either, and
mark full definition at-risk to see what ppl implement in CR
arronei: I still think that UAs /may/ support up to 100,000 but may support
numbers higher and leave it undefined
TabAtkins: You do have to define it because it's complex and ppl /will/
get it wrong
fantasai: And we have the correct definitions already
TabAtkins: I don't want ppl to get fallback in one UA, correct result in
another UA, and wrong result in another UA because they got
it wrong
<dsinger> UAs are always at liberty to exceed requirements. you don't
even have to say it
glazou: You can always add a note that CSSWG might define beyond the
limit later
glazou: Put the definition to 100,000, allow UAs to go beyond, and add
the note
<dsinger> I just think it might be safer to define what they should do
beyond the conformance limit, if they want to. it can be
purely informative text
fantasai: We have the definition, if we're allowing UAs to go beyond the
limit, I don't see any reason not to put the definition in the spec
<dsinger> as I say, you can't prohibit people from doing more than is required
5) Define up to 100,000, allow UA to go beyond it, but DONT put a
definition in for beyond 100,000
6) Define up 100,000 allow UA to go beyond it, put an informative
definition in for beyond 100,000
We'll put a note for all of them that CSS may define beyond that later
TabAtkins: I prefer 3, can live with 1
dweck: My knowldge is limited. Abstain
sylvaing: I think 6 works for me
<dsinger> (1) is a testing nightmare, isn't it?
arno: Go with 3, but live with 6
smfr: 6
<smfr> let's give Tab more work :)
koji: I prefer 6
arronei: 6
césar: not sure
Bert: no opinion
glazou: 6
bradk: 6
plinss: I prefer 4, could live with 6
<dsinger> dave defers to smfr (he's always right): 6
hober: I prefer 6, but happy for tab to do less work as 3
szilles: prefer 3, live with 6
johnjan: prefers 6, very against 2
fantasai: same as plinss
RESOLVED: Define up to 100,000 with fallback to cjk-decimal beyond, allow
UAs to implement longhand beyond that limit, put definition in
informative appendix
new width keywords for CSS3
---------------------------
<fantasai> http://lists.w3.org/Archives/Member/w3c-css-wg/2011AprJun/0245.html
Back in 2007, the CSS Working Group resolved to add four new width values
to CSS3: min-content, max-content, fit-content, and available:
http://lists.w3.org/Archives/Public/www-style/2007Nov/0119.html
These represent the values of various width computations that UAs need
to support in order to do float and table layout, and give authors direct
access to those algorithms in the 'width', 'min-width', and 'max-width'
properties.
In 2008, dbaron blogged about these values and their implementation in
Mozilla:
http://dbaron.org/log/20080613-firefox3-css#new-width-values
It's now 2011, and as I am speccing out the layout algorithms for orthogonal
flows in CSS3 Writing Modes, I find I need to refer to, and define behavior
for, these width computations. So I adopted the keywords as terminology in
Appendix B:
http://www.w3.org/TR/2011/WD-css3-writing-modes-20110428/#appendix-b-intrinsic-sizing
Since I have to define these concepts anyway, and since we have a resolution
for these keywords anyway, and since those keywords *are* especially useful
in the mixed-direction layouts we are introducing with vertical text, I was
wondering if it might make sense, given that CSS3 Box is nowhere near CR for
us to refer to, to just define the keywords in CSS3 Writing Modes. I think it
would be helpful to authors to have these values available sooner rather than
later.
TabAtkins: I'm going to want them defined because I need them in FlexBox
for similar reasons
plinss: I'd like to see these width values advance as quickly as possible
plinss: My concern is that UAs that don't want to support vertical mode
fantasai: We can make it explicit that you can implement the module in parts,
maybe make profiles
plinss: Is that the best place to put it?
fantasai: I think so
plinss: Can we make a small box module for this?
fantasai: We've tried trimming down the box module multiple times, it doesn't
move because we have to clean up CSS2.1 in it.
Bert: torn between elika and peter, would be hard to split it out
szilles: We should get it in and get it reviewed
arronei: put it in values and units?
fantasai: no, it's very tied to layout
fantasai: I have to define the concepts in writing modes anyway, I can just
say 'btw, here are keywords for this'
fantasai: Can make a new section for it
fantasai: right now it's an appendix, could even leave it in the appendix
szilles: normative appendix sounds good to me
plinss: and all parts Tab would refer to are in that appendix?
fantasai: yeah
fantasai: if you really want to split it out later, let's do it as an
editorial change in CR
<szilles> +1 for a normative appendix in Writing Modes
arronei: make sure it's normative
arronei: I would prefer a separate spec, but not against making it a
normative appendix
szilles: I agree that it really belongs in the Box Module, but it needs
to be in something that's progressing faster than the box module.
szilles: By making it an appendix, it makes it clearer that this is a
separable piece that can/might be used elsewhere
arronei: Maybe add a note that this might be moved to e.g. future version
of box module
RESOLVED: Add these keywords as an appendix, add note that they might be moved
CSS Regions
-----------
szilles: Would like to give 1-week notice of request to publish WD of Regions.
szilles: Exclusions still needs more work.
szilles: hyatt posted some issues to www-style
plinss: OK
Meeting closed.
Received on Wednesday, 11 May 2011 18:19:30 UTC