[CSSWG] Minutes and Resolutions 2009-02-11


   - Discussed Unicode Normalization and Selectors, what to do about publishing

   - Publication of CSS3 Backgrounds and Borders LC deferred due to discussion
     of border-image and box-shadow interaction on the mailing list.

   - Everyone should review Apple's drafts for Animations, Transitions, and
     Transforms: next week we will decide whether to publish them as official
     Working Drafts.

   - RESOLVED: Publish new CR of CSS2.1 once pending edits have been made and

   - Discussed @font-face and duplication issues dbaron posted

   - RESOLVED: list-style-type 'armenian' maps to 'upper-armenian'

   - RESOLVED: Proposal for CSS2.1 Issue 84 accepted with spelling correction
     for "zero with space".

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


   David Baron
   Bert Bos
   John Daggett
   Arron Eicholz
   Elika J Etemad
   Sylvain Galineau
   Daniel Glazman
   Håkon Wium Lie
   Chris Lilley
   David Singer
   Anne van Kesteren
   Steve Zilles

ScribeNick: fantasai


   Daniel: Two extra agenda items
   Daniel: First is a request from Apple to publish their new drafts
   Daniel: Second is a suggestion from Bert to publish a new CR
   Daniel: of CSS2.1
   <glazou> http://lists.w3.org/Archives/Member/w3c-css-wg/2009JanMar/0063.html
   Daniel: Falls into agenda item for publication of LC for Selectors and

Selectors Publication and Normalization

   Daniel summarizes what the Normalization issue is
   Daniel: In Unicode there are multiple codepoint combinations that will
           result in the same logical character
   Daniel: For example, if I type e+acute on Mac and on Win, they do not
           necessarily match
   Daniel: The issue is important enough that we should know what to do
   Daniel: I have an example of the style sheet being provided on the Mac,
           and the HTML being written on a Windows machine
   Daniel: I have to note that normalizing to NFC or NFD is not difficult
   Daniel: Richard Ishida published a script on his blog that does this
   fantasai: it's in a lot of libraries
   Daniel: I definitely agree this is an issue related to OS and input methods
   Daniel: But since these won't be fixed soon, it's the browser's task
   Daniel: I don't think the user should know anything about it
   Daniel: So I agree we should defer the publication of Selectors

CSS3 Backgrounds

   Daniel: What about css3-background?
   fantasai: There have been a few issues that came up recently
   fantasai: One is that people on the mailing list objected to our resolution
             that box-shadow doesn't get suppressed by border-image
   <Zakim> ... Bert, plinss, hsivonen, Hixie
   fantasai: Another is whether the 'border' shorthand should suppress

Publishing Apple's Drafts

   Daniel: Back to Apple's drafts. Has anyone had a chance to review them?
   Daniel: I suggest to defer this agenda item to next week
   Daniel: Ask everyone to review them and come with an opinion next week
           about whether we should publish these drafts

Publishing CSS2.1

   <Zakim> +David_Baron
   Daniel: Last sub-item is about releasing a new CR of CSS2.1
   Bert: I think I have edited all the things that we decided on editing
   Bert: There are a few open issues
   Bert: It's been a year and a half since we published
   Bert: I think it's about time we published a new version
   fantasai: I agree we should publish, but there were a few missed edits
   RESOLVED: Publish new CR of CSS2.1 once edits have been reviewed and

@font-face and Duplication

   jdaggett: Let me post the URL to David's original post
   <jdaggettSleepy> http://lists.w3.org/Archives/Public/www-style/2008Nov/0077.html
   jdaggett: This post is rather long, and there are three items in it.
   jdaggett: The first one, I think everyone agrees that that makes sense
   jdaggett: If you have two descriptors within an @font-face rule, the
             second descriptor overrides
   jdaggett: The second and third items are more of an issue
   jdaggett: The second item is for the src descriptor, whether the src
             descriptor implies load behavior
   jdaggett: or whether it implies both load behavior and font fallback
   dbaron: I got the example in that message backwards
   <jdaggettSleepy> example
   <jdaggettSleepy> http://lists.w3.org/Archives/Public/www-style/2009Jan/0290.html
   <Zakim> +howcome
   jdaggett: The idea with the load behavior is, for example, if you have
             local FontA and local FontB
   jdaggett: you only load the first one that you actually find
   jdaggett: or if you have a URL with a specific font resource
   jdaggett: once you find something and successfully load it, you ignore
             the items that are to the right of that in the src list
   chrisl: I think that's consistent with the original idea, where you had
           multiple formats for different platforms
   jdaggett: That makes sense, but there were some people who suggested
             that fallbacks was a more CSS-like way to handle it
   jdaggett: ... For example, if you include on the Mac an Arabic font,
             followed by an OpenType face
   jdaggett: On the Mac you'd have to load both
   jdaggett: I don't think there was a lot of controversy around that
   jdaggett: I think what was more controversial was item 3
   jdaggett: It was more related to how the Unicode-range descriptor works
   jdaggett: although that's not totally clear from the original example
   jdaggett: Example is, if you have 2 font-face rules that only differ in
             their src descriptor
   jdaggett: whether the second rule overrides the first
   chrisl: No, it should add to it
   jdaggett: The problem with this example is that there's unicode-range
             with the full range
   jdaggett: now, the interesting thing is, how WebKit implemented unicode-range
   jdaggett: Unicode-range is seen as the range specified intersected with the
             actual character map of the font
   <ChrisL> The character map for a downloaded font is the intersection of the
             unicode-range value, U+0-7FFFFFFF by default, and the actual
             character map contained in the font data.  This is WebKit latest
   jdaggett: So effectively if you're to have these two rules, from dbaron's
             original posting, you would have a font that would first try to
             load b.ttf
   jdaggett: but if it couldn't find a specific character in b.ttf, it would
             fall back to a.ttf
   jdaggett: That's simply in the subtle way that unicode-range is defined in
   ?: Is that the same as src: a.ttf, b.ttf; ?
   jdaggett: No, that would only load the first one
   ChrisL: I wanted to talk a little about the history here
   ChrisL: I gave a talk at Unicode about Fonts
   ChrisL: Someone passed me a note
   ChrisL: and he said afterward, Very nice talk, but I think you should be
           able to combine multiple fonts into a single composite font.
   ChrisL: I asked him if he had a card, and he said yes. It said Donald Knuth.
   <ChrisL> Donald Knuth was the person asking for composite font support
   howcome: John, do you have something specced out that you are comfortable
   jdaggett: Yes
   <Zakim> +anne
   jdaggett: The current Editor's Draft defines the src descriptor to specify
             the load behavior
   * anne will be in Tokyo; is now locally muted
   howcome: Is this compatible with Prince's current behavior?
   jdaggett: Prince's behavior gets into the behavior of local(), which I don't
             necessarily agree here
   howcome: There is an implementation there...
   jdaggett: I don't think it behaves in a clear and [?] way
   jdaggett: Basically, this boils down to the compounding behavior of
   jdaggett: and the way it combines is very subtle
   ChrisL: I think the way you have it in the spec is very good
   jdaggett: It makes the simple cases easy, and the complex cases possible
   howcome: So you can effect Prince's behavior by just changing the syntax?
   jdaggett: Yes.
   howcome: But it's more complex syntax
   jdaggett: Yes.
   jdaggett: Michael wants the family name to be the ?? name
   jdaggett: that a single descriptor describes a single face, not a single
   <Bert> (I prefer: (1) take only the first available resource from the
           'src' list; (2) make composite fonts from multiple @font-face
           rules with same font-* descriptors based on unicode-range;
           (3) handle fallbacks with the normal 'font-family' proeprty.)
   jdaggett: I think it would be better to have Michael here, I can't really
             defend his idea.
   jdaggett: If you go back to the thread, if you concatenate all those
             you'll get the gist of what the argument is
   howcome: You're saying that your current Editor's Draft reflects your stand?
   jdaggett: yes
   jdaggett matches the currently-specced behavior to answers to dbaron's
     questions, but I didn't catch exactly how
   jdaggett: At the F2F we could go into more detail.
   howcome: Can we get Michael to call in, would that be possible?
   SteveZ: I have one question. Can we get some use cases which help elucidate
           these things?
   jdaggett: Sure. The spec has some, but it could use more.
   ChrisL: The classic example is, you have a Japanese font that has bad Latin,
           and you have a font which is good Latin
   * dbaron steps away for a minute
   ChrisL: But the Latin font has bad kana
   ChrisL: so you have to use unicode-range, simple fallback isn't enough
   SteveZ: Why is 2 the solution to item 3
   jdaggett: Because in this case unicode-range is implied
   jdaggett: The subtle way this works, the actual unicode-range used is the
             intersection of the unicode-range described in the @font-face
             rule and the actual range of characters in the character map of
             the font
   SteveZ: I need to study this more, but at least this tells me what to
           look at.
   Daniel: I suggest we stop the discussion here and continue in Tokyo
   Daniel: Thank you for attending the conf call in the middle of the night
   Daniel: Next agenda item


   Daniel: Next item, armenian numbering
   Daniel: It seems Armenian works like lower-roman and upper-roman. You
           can use upper-armenian or lower-armenian.
   Daniel: 'armenian' shouldn't exist
   fantasai: but it's a value in 2.1, and it's implemented already
   Daniel: It's really difficult to make a choice
   * dbaron is back
   fantasai: Richard looked into what implementations do, and they use
             upper case
   Daniel: The most common case seems to be lower-armenian
   fantasai: But is it worth breaking compatibility?
   Sylvain: We talked to a few Armenian developers and they didn't have
            a strong opinion either way
   Daniel: I will ping the Armenian embassy in paris
   fantasai: we have feedback from an Armenian typographer already
   fantasai quotes from Richard's text
   Daniel wants to ask someone before making a decision
   SteveZ: First thing, asking random people will give you random feedback
   SteveZ: Second, who would give you reliable feedback? I don't think the
           Armenian embassy would be a good place to look
   ChrisL: You're looking for the Armenian equivalent of the Impremerie
   howcome: Maybe you're looking for something that doesn't exist
   <dsinger> ? http://translations.com/_Armenian_website_globalization.html
   Daniel: Give me a few days.
   Daniel says something about this affecting defaults for Armenian locale
   fantasai: locale does not matter
   fantasai: Ask also whether it would be worth changing existing
            implementations and the expectation of any authors who are
            already using armenian numbering
   <dsinger> I want Nagorno-Karabakhish numbering
   fantasai: This isn't a locale issue, you only get Armenian numbering
             if you ask for it with list-style-type
   fantasai: And right now authors are getting upper-armenian
   TENTATIVE RESOLUTION: armenian maps to upper-armenian
   PENDING: Daniel's investigation report

CSS2.1 Issues

   <fantasai> We have Issue 84
   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-84
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Nov/0082.html
   <glazou> http://lists.w3.org/Archives/Public/www-style/2008Nov/0082.html
   Sylvain: I'm ok with it, I'm asking Arron if he's ok with it
   Bert: I think that's good enough for CSS2.1. Might be more precise in level 3
   <dbaron> it should say "zero width space" rather than "zero with space"
   RESOLVED: Accepted with dbaron's spelling correction

Unicode Normalization

   fantasai: I'd like to get an idea of what people think of Normalization
             for Selectors
   dbaron: I don't want normalization at each API layer
   dbaron: I want normalization at a much more general layer
   dbaron: Like normalizing on input
   dbaron: when you do the character encoding step
   dbaron: The issue isn't just with CSS
   <anne> Opera strongly supports what David just said
   <anne> Though we'm concerned that doing normalization of XML, HTML, etc.
          at this point will break existing scripts
   Daniel: My concern is that users shouldn't have to worry about this issue
   fantasai: For Selectors, perhaps we could treat it like case-sensitivity
   fantasai: Let it be defined by the document language
   Daniel, Bert, dbaron: I don't think it's the same thing
   Bert: You can see the case
   dbaron: Sometimes the unnormalizable characters are excluded from nmchars
   <anne> So nobody heard me? :/ I was saying that for e.g. XML it is the
          same thing. XML does not make a difference between NFC and NFD
          (XML parsers don't at least). Same goes for ECMAScript and HTML
          at this point
   <fantasai> anne, isn't that the opposite of what you said on the ml?
   <dsinger> silence...
   <dbaron> anne, you need to unmute your phone too
   <anne> I did :/
   <dsinger> and talk
   <sylvaing> it's a complex protocol
   <anne> I did ;)
   <sylvaing> too many dependencies
   <anne> that's true glazou :)

Meeting closed.

   * fantasai concludes that Selectors will never progress
   <glazou> fantasai: oh come on
   <anne> fantasai, Selectors needs to be able to match both NFC and NFD XML
         IDs and XML documents that use both, imo
   <glazou> yes
   <glazou> so to match both, you need to normalize to one of them
   <glazou> and match
   <anne> then you make two IDs equal that might be different
   <fantasai> anne: Does XML match an NFC start tag with an NFD end tag?
   <glazou> no
   <glazou> composition(e, acute) == é
   <anne> fantasai, nope, it's based on codepoints, not Unicode characters
   <glazou> that's the same for authors
   <anne> but not the same in XML
   <anne> or ECMAScript or HTML or CSS at this point
   <glazou> anne, if a user inputs an attribute value
   <glazou> set by JS
   <glazou> how do you make the difference ?
   <glazou> user types composition(e, acute), ends up in class attr
   <glazou> and stylesheet uses class .é
   <glazou> ?
   <glazou> then the page has to normalize ???
   <anne> i'm not sure it's a matter of me making a difference, it's a
          matter of the specs dictating that no normalization happens
   <fantasai> I conclude that we should publish LC ignoring the normalization
              issue so at least we have an updated draft for the next year
              while i18n and the browser vendors debate the relative merits
              of this or that normalization scheme
   <anne> yeah, that sounds fine to me
   <anne> we can add authoring advice just like XML and ECMAScript did though
   <fantasai> good idea
   <anne> that recommends that authors always write CSS and host languages
          in NFC
   <glazou> you cannot request that
   <glazou> authos now nothing about normalization
   <anne> if that works for XML, it should be good enough for CSS too, and
          validators can flag it
   <anne> authors know nothing about encoding either

Received on Tuesday, 17 February 2009 20:07:45 UTC