- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 17 Feb 2009 12:07:00 -0800
- To: www-style@w3.org
Summary:
- Discussed Unicode Normalization and Selectors, what to do about publishing
Selectors.
- 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
verified.
- Discussed @font-face and duplication issues dbaron posted
http://lists.w3.org/Archives/Public/www-style/2008Nov/0077.html
- RESOLVED: list-style-type 'armenian' maps to 'upper-armenian'
- RESOLVED: Proposal for CSS2.1 Issue 84 accepted with spelling correction
for "zero with space".
http://wiki.csswg.org/spec/css2.1#issue-84
http://lists.w3.org/Archives/Public/www-style/2008Nov/0082.html
====== Full minutes below ======
Attendees:
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
Agenda
------
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
css3-background
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
border-image
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
completed
@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
behavior.
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
WebKit
?: 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
with?
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
unicode-range
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
family
<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
Armenian
--------
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
Nationale
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