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

[CSSWG] Minutes and Resolutions 2011-05-11

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 11 May 2011 11:18:26 -0700
Message-ID: <4DCAD2F2.9060207@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

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

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

   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


   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

   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
   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:
       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'

       In 2008, dbaron blogged about these values and their implementation in

       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:

       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

   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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:45 UTC