W3C home > Mailing lists > Public > www-style@w3.org > September 2008

[CSSWG] Minutes F2F 2008-08-21

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 08 Sep 2008 18:55:56 -0700
Message-ID: <48C5D7AC.7000504@inkedblade.net>
To: www-style@w3.org

    David Baron
    Bert Bos (staff contact)
    John Daggett
    Arron Eicholz (via phone+IRC)
    Elika Etemad
    Daniel Glazman (chair)
    Richard Ishida (observer)
    Anne van Kesteren
    Philippe Le Hégaret
    Håkon Wium Lie
    Peter Linss (chair)
    Alex Mogilevsky
    Saloni Mira Rai
    Steve Zilles

<RRSAgent> Logging to http://www.w3.org/2008/08/21-css-irc
Scribe: dbaron
Meeting: CSS Working Group Face-to-Face


   Håkon: This draft is a clearinghouse for print-related features that
          didn't fit elsewhere.
   Håkon: Until recently, it's mainly prince, but we've recently heard of
          another implementation.
   Håkon: The draft has moved a bit recently.  Posted a new editor's draft
          based on feedback.
   Håkon: Stable parts: running headers/footers, leaders, footnotes,
          hyphenation, image resolution, cross-references, page marks,
          bookmarks, CMYK colors
   Håkon: These have implementations and not many requests for changes.
   Håkon: Developing parts: named page lists (page sequences), character
          substitution, page floats.
   PLH: Intended only for print media?
   Håkon: That's currently in the document that it's only intended for
          print media, but some could be reused outside of print.
   <fantasai> Should be here: http://dev.w3.org/csswg/css3-gcpm (but
              dev.w3.org is not loading)
   Alex: Most things in the spec could apply to interactive view.  But
         some things wouldn't work well there.  Do we want to look at
         this ignoring interactive view, or considering it?
   <glazou> fantasai: http://www.w3.org/Style/Group/css3-src/css3-gcpm/Overview.html
   Bert: Not for the module to say what's for what media type; that's for
         the profile.
   Håkon: I don't want this to be a threat to, e.g., progressive rendering.
   Peter: I want browsers to support this when they're printing.
   Håkon: absolutely
   Alex: There are very few features that are only print-specific.  So
         I'm not sure how much value is in ignoring interaction when we
         discuss this -- or can we get ourselves in trouble by making
         things that are hard to make interactive.
   Elika: I think we probably want some pieces to move to other drafts.

   (discussion about whether cmyk() is actually defined, etc.)
   Steve: ICC probably has something that talks about CMYK, but I don't
          know what off the top of my head

GCPM: border-length

   Håkon: Another feature that can be reused is border-length.
   Elika: We could reuse border-radius and have a border-corner-shape
   Peter: Wouldn't that preclude rounded corders like that?
   David: This seems separate from border-radius.
   Elika: border-corner-shape: [ sides | corner ] || [ round | sharp ]
   Alex: border-length is a little more intuitive
   Håkon: What about covering only non-corners.
   Steve: Concern about overloading radius.
   Steve: Can't use radius for both amount to show and the curvature.
   Håkon: Maybe syntax from border-radius, but on a new property?
   Elika: But we'd want it to take percentages.
   Elika: And you'd want to be able to invert it to take only the middle.
   Bert: Do we really need all this, given border-image and SVG?
   Håkon: This came out of a simple request for footnotes.
   Håkon: But it seems to be reusable.  I've seen all these limited borders
          since I started this.
   ?: Can we put it in backgrounds and borders?
   Elika: Yes... but we should mark it at risk.
   Peter: Implementations?
   Håkon: No
   Håkon: So we want a new property like border-radius, plus another new
          property for the shape (e.g., for diagonal corner, or for inverted).
   Alex: What happens when length is less than radius?
   Steve: It's a mask.
   Steve: I'd suggest calling it 'border-mask'.
   David: That sounds like something else.
   Steve: 'border-clip' ?
   Daniel: This goes far beyond gcpm.
   ?: to borders and backgrounds
   Steve: Math people want adjustable brackets.
   Elika: You don't want that with borders - you want a font.
   Peter: What's the 'auto' value?
   Håkon: 'auto' within lists copies from a different corner
   Peter: Initial value should be a complete border.
   Peter: Is that 'auto'?
   Håkon: OK, 'auto' should be the initial value and mean the complete border
          is used.
   David: You could make v/h %ages refer to width/height.
   Alex: Then you can't get %ages square.

GCMP: Text Replacement

   Håkon: Text replacement:  necessary for printing to fix up quote characters.
   Daniel: This is transformation, not style.
   Daniel: Transformations of the document with a simple syntax are needed.
           I did that 10 years ago with STTS.  But don't call that CSS.
   Håkon: We should have a new content type?
   Daniel: No, but put it in another spec.
   Daniel: I have no problem mixing it with text/css, but put it in another
   Steve: If there were an element there, I could do it with 'content' and
          it would be style.
   Steve: If the selectors allowed me to select a given textual string and
          make it a pseudo-element, then that would be consistent with the
          rest of the language.
   Steve: The point here is that it's un-marked-up elements.
   Håkon: This example (s/Soviet Union/Russia/) was meant to scare the kids.
   Daniel: This should be a script that the printer driver offers you.
   Steve: There's no reason I don't want to see this on the screen.
   Daniel: Once we do this, people will want much more transformation.
   Alex: Open quotes and close quotes are harder.
   Daniel: Having transformations with CSS syntax has problems with the
Scribe: fantasai
   Daniel: You can transform the document in ways that cause further
   Daniel: And you can get into a loop that way
   Daniel: You want transformations as a sequence
   Daniel: That is why I did not combine STTS with CSS
   Steve: THis problem came up in XML and it was never simple
   Howcome: THis doesn't change the structure of the document.
   Bert, Fantasai, Daniel: Not yet.
   Håkon: The replacements are applied sequentially.
   Howcome: the text replacements are sequential according to the list in
            the text-replace property
   David: Is it inherited?
   Daniel: body { text-replace: "Soviet Union" "Russia"; }
           p { text-replace: "Russia" "Soviet Union"; }
           What happens?
   Fantasai: It doesn't matter in this case
   Daniel: If you want to solve the problem of circular transformation
   Daniel: You can do that with a selector.
   Daniel: If you have "Soviet Union" over two different elements, what is
           the result?
   Howcome: In Prince you cannot make matches across element boundaries.
   Alex: In case something in GCPM doesn't make it into CSS3 whatever, do
         we have a plan of what happens to it?
   Alex: Is GCPM going to be a home for things we're not doing yet and
         pull out things like page floats that we find popular into other
   Howcome: We should do that, but there are a core set of functionality
            like footnotes that are paged media specific
   Peter, Alex: I don't think footnotes are paged-media specific
   Daniel: back to text-replace. First, it's really underspecified.
   * anne wonders if the footnotes stuff works together with the minimum
          HTML5 did for footnotes
   Daniel: Second, I can agree on the usefulness. I want it in a standalone
           document. It does not belong to style.
   Howcome: It's not going to get it's own document type.
   Daniel: Why not
   Bert mentions XSLT
   Discussion about how this doesn't go far enough to be useful for some
     of the major use cases unless you have regex..
   Steve: In the font capability we're thinking of extending the font
          feature to enable open-type features.
   Steve: That would solve your quote problem.
   <anne> (though I suppose you could match on ' "' and '."' or something)
   Steve: There are features in the font that allow you to trigger mappings
          of character to glyphs
   John: For example, a lot of fonts enable a slashed zero. They have an
         alternate glyph, and you can enable that feature.
   Howcome: That might turn out to be a solution. I personally cannot edit
   John: You'd specify it through font-variant
   <Bert> (I do need (and use daily) something of the power of XSLT. Would
          be nice if there were something with a better syntax, but I want
          people to have the choice to use XSLT as well. Hence we need to
          keep this separate from CSS.)
   Peter: I think the thing you match against the original text.
   David: Then you have to merge the replacements.
   David: What happens if your replacements overlap? E.g. you replace
          "Soviet Union" and you replace "Union".
   Howcome: You define a sequence. There's no infinite loop here.
   Ishida: What is your use case here?
   Ishida: You've got a document someone has written, and you want to print it?
   Howcome: Or I wrote it. I don't want to type the long unicode sequences.
   Peter: That's a very weak argument. If you're talking about a document you
          didn't write, then you have a use case.
   Daniel: These are not something you are associating with the document anyway.
   Daniel: So it is a local thing. You don't need a MIME type
   Peter: I can see you using it in a collaborative process when someone scans
          text and posts it, someone else writes a style sheet for it.
   fantasai: why can't it be a separate transformation sheet, like XSLT or STTS?
   Daniel: body { text-replace: "Soviet" "Russia"; }
           p { text-replace: "Soviet" "CEI"; }
Scribe: dbaron
   Håkon: The replacements on ancestors would happen before replacements on
   Elika: This shouldn't be in CSS, so you can have all the declarations
          apply rather than having them override each other by cascading and
   Steve: Should record: with the selector approach, you have the overlap
   <dbaron> *:text("Soviet") { content: "CEI"; }
   David: If you make this an inherited property, then you have more overriding
          happening and you don't have these problems.
   David: Only one text-replace value ever applies to a given run of text.
   Håkon: I think we should take what we have two implementations of and make
          a spec of it.
   Steve: I think this feature should be a separate document.
   Peter: I think it depends on how this feature is defined.
   Håkon: I'm happy to make a separate document out of it, as long as it's not
          taken out to be killed.
   Steve: I think there are a number of options on the table, and making it a
          separate document lets us pursue those options.
   Peter: My other concern there is that we're rechartering, and we have a small
          number of modules to make progress on.
   <anne> (that should be ::text fwiw)
   <anne> (though the board is indeed wrong)
   Peter: I'm comfortable leaving it here until it's cooked; most of this seems
          like it can be moved into other modules.

GCPM: Bookmarks

   Håkon: Bookmarks.
   Håkon: This is a way to generate PDF bookmarks.
   Håkon: It's modeled after what PDF can take.
   Daniel: It's like a TOC.
   Steve: It's a tree.
   Daniel: It's a way of copying some element into a new special box?
   Håkon: It's not a box, it's a logical structure.
   Alex: Why not call it table-of-contents-level?
   Anne: How is it stylistic?
   Håkon: You need this when you generate PDF.
   Anne: Can't HTML specify this?
   <Bert> (<link rel=bookmark href="#sect5">)
   Anne: The PDF generator should just extract it from the semantics of the
   Steve: If it's an XML document, how do you do it?
   Håkon: This is a pragmatic issue for CSS processors that want to create
          PDF files.
   <anne> (If it's XML you convert it to XHTML.)
   Alex: It's information used in another output format.
   Alex: It doesn't have to be CSS if it doesn't have any rendering effect
         in CSS
   Elika: It's adding semantic metadata to the document, not style.
   Alex: You could also have the data in a META in the HTML.
   Steve: But the selectors are more powerful.
   Daniel: Why don't you use counters?
   Elika: This is trying to do transformations and semantic tagging (using
          the power of selectors), which don't belong in style sheets.
   Håkon: We're doing links and ??? in Opera ... we're not going to take that
   Steve: We have electronic presentation forms, of which the bookmarks are
          a part.
   Peter: I agree that this is a presentational issue.
   Elika: Displaying the title of the document in the window title bar is
          similar, but we shouldn't do that in CSS.
   Peter: I don't think this is absolutely out of scope.
   Steve: If you want to claim CSS applies outside HTML, there's no way for
          an XML document to put something in the title.
   Peter: Putting the window title in HTML is violating separation of
          presentation and content.
   Elika: It's not about presentation; it's the title of the document.
   Peter: These distinctions aren't always obvious.
   Elika: You want to say "I am the title of the document", not "put me in
          the title bar".
   Elika: That's semantic tagging.
   Elika: The title is used for more than the title of the window, it's also
          used for bookmarking and in history
   Elika: And other places in the UI
   Elika: You want to do that with other XML formats, but you don't want to
          do it by saying "Put me in the title bar", you want to do it by
          saying "I am the title, present me appropriately". And that is
          semantic tagging, not styling.
   Peter: I don't want to kill it right off the bat.
   Bert: No, let's kill it.
   Daniel: In Håkon's proposal, the bookmarks themselves cannot be styled.
   Håkon: PDF can't do it.
   ?: Although that doesn't mean a browser couldn't.
   Håkon: This is a necessary feature for those of us who generate PDF files.
   Steve: Where would you put it?
   Elika: Some semantic tagging language.
   Håkon: Authors won't specify this.
   David: It's in the user agent (e.g., style sheet... although preferably not).
   Richard: ?
   Anne: H1 would just be part of the document outline
   Steve: What level of headings would you stop at?
   Anne: Why would you stop?
   Daniel: Limit depth.
   Bert: Collapsable lists... leave that to the user.
   Daniel: We see the power of doing this with CSS syntax, etc., but we don't
           agree it should be in CSS
   Håkon: It's in GCPM, which is in a separate space.
   Anne: Document outline is in HTML5.
   Steve: Did you look at XSL-FO for bookmarks?
   Håkon: I should.

   <br />

Extensions to the float property

Scribe: fantasai
   Howcome: Discussed on the mailing list recently. Antenna House has lots of
            good ideas.
   Howcome: There are four different alternatives.
   Howcome: First we extend float with 'inside' and 'outside'.
   Howcome: synonyms for left and right depending on which page you're on
   Howcome: Then we add 'top' 'bottom for vertical
   Howcome: Then we have reference keywords: 'page', 'column', 'multi-column'
   Howcome: Then we have conditional keywords: 'unless-room' | 'hide-unless-room'
   Howcome: so that advertisers can use any unused whitespace on the page
   Alex: you could have adverts of different size
   Howcome: float: top next page unless-room; Moves figure to top of next page
            unless room on current page
   Alex: How is this different from the default behavior of floats?
   Howcome draws on the whiteboard two pages
   first page-half-filled with text
   then a large image
   that doesn't fit
   normally it gets pushed to the next page
   and text fills after the image
   this would allow the image to shift over to the next page
   bu the text to continue filling on the first page
   Alex: Couldn't that just be regular float and clear?
   top allows float to move above placeholder
   Peter: that can get you into potential race conditions
   Alex: that can be resolved
   <Bert> ("float: top next page unless room" could be more compactly be
          called "float: here")
   Bert: you want the image centered. You only float it if it doesn't fit:
         it's not floated to any side.
   Howcome: you might want it to go to the bottom of the next page if it
            doesn't fit
   Steve: There's two cases
   Steve: It either fits on the page with the callout or it doesn't
   Steve: If it fits on the page, there are subcases. It would fit at the
          top, the bottom, or somewhere near the callout
   Steve: If it doesn't fit on the page, you may want to specify where it
          should go when it doesn't fit
   Steve: You want to specify where to put it if it does fit, and where to
          put it if it doesn't fit.
   Peter: Can this be done with page-break controls, or widow orphans, or
          something else
   Howcome: This case ('here') is non-floating
   fits or not?
     yes -- top | here bottom
   s/here bottom/here | bottom/
     no --
   Alex: We want to allow multiple figures with columns... we have to
         communicate intent that this should be regular float that should
         be anchored
   <Bert> (Or a fallback list, comma-separated, max. two items:
          'float: here, top')
   Howcome: There are some cases where you're not floating, but if there
            isn't room you want to float
   Peter: Maybe you want to break out the notion of whether it fits.
   Peter: Maybe you want to absolutely position the thing if it doesn't fits
   Steve: So here's an example. If it fits on this page I want it at the
          bottom. If it doesn't fit on this page I want it at the top of
          the next page
   Steve: other cases are it's not floated at all if it fits, but floated
          to next page if it doesn't
   Steve: You don't want a break in the text. You just want it to flow.
   Bert: I heard from Steve the use cases.
   Bert: You place it this way if it fits, that way if it doesn't
   Bert: Why not have a comma.
   Bert: to separate the alternatives.
   Bert: Then you don't have this unless keywords which ar so confusing.
   Howcome: Suppose I have to floats that say 'top'. Are these floats both
            at the top, or does one go to the next page.
   Howcome: so it can be at the top?
   Steve: They're both floated to the top, show up in source order.
   David: Pushing to the next page sounds like the clear property
Scribe: dbaron
   Steve: Having 50% wide float then 100% wide float on top looks ugly
   Håkon: With a very intelligent process you could fix that.
   Alex: Grid positioning, with places in grid for bigger and smaller images.
   Steve: Need a template.
   Alex: With templates ... handle wanting at most one picture per page.
   Håkon: float:top, clear: ?
   David: clear:top ?
   Alex: in this case you want just the float to clear, not the content
         that comes after
   Steve: If you think it's complicated now...
   Håkon: Maybe an argument for having separate vertical and horizontal
          floating properties?
   Elika: Better in the same property for cascading, etc.
   Elika: But maybe "unless-room", etc., could be a separate property.
   David: What if float:left and v-float: top?
   Steve, Alex: That's ok.
   Bert: float: left | right | here | top | bottom
   Bert: float property can accept two comma-separated values
   Bert: float: [left | right | none | top | bottom], [left | right |
          hidden | top | bottom]
   (People discuss whether none is in the second list.)
   float: none, * is the same as float: none
   Steve: 'float: top, none' means top if it fits on the page, in-flow if
          it doesn't (and at the top of the next page)
   Alex: I'd like to hear from a designer that they want this conditional
   Elika: Should you need the 'page' keyword for these examples?
   Howcome: that's another question, should 'top'/'bottom' imply 'page'?
   Howcome: There's a use case for floating to the top of the containing
   Elika: Designers really want that.
   Alex: For float anywhere on the page, we need keywords for top, left,
         right, bottom, plus keywords for abs pos CB and for page.
   Peter: I can see floating to an arbitrary grid line.
   Elika: Can we assume that these floats never escape the block formatting
          context we're in?
   Discussion of grid positioning
   Alex: I'm used to the Word model where you position an element on the
         page and then set the text wrap
   Alex: In terms of positioning (ignoring wrapping around them),there are
         some things that can be done with floats that can't be done with
         abs pos, and vice versa.
   <Bert> (You can wrap text around abs. pos. element only if the coordinate
          system for positioning doesn't depend on the position/size of the
           element itself.)
   (discussion of floating versus positioning)
   Alex: just for reference, word allows positioning anywhere but not
         relative to auto-sized elements
   Alex: so we'd get some very interesting issues if we have an auto-balanced
         multicol element with boxes floated to the bottom

   Richard: Arabic books or Chinese books, where the page on the right face
            comes before the page on the left face...
   Håkon: top is top, left is left, etc.
   Richard: So in a vertical document, if I want a page float at the start
            of the text...
   Alex: We consider 'top' and 'left' as synonyms given CSS2 floats that
         only go at the sides of the lines.
   Peter, Alex: Do we want inside, outside, start, end?
   ...before, after.
   Håkon: I don't accept the requirement that the same style sheet should be
          used for Arabic and English.
   Richard: I've spoken to people who translate to Arabic and find this
            very difficult.
   (discussion of before, after, start, end, etc.)
   Håkon: 'before page' is confusing
   Elika: If you're designing a site that you know is going to be translated,
          you want to design the style sheet once.
Scribe: fantasai
   Bert and Howcome don't think in a way that this makes sense
   Alex: Approximately 50% of the people in this room see a legit use case
         for this
   Peter: We have people in this room who specialize in internationalization
          and writing in different scripts, I think we should listen to them.
   Richard: So Bert, you need to find people who back up your propositionin
            the Arabic and Hebrew-speaking world.
   Richard: Let me be clear that sometimes you set left and you always want
            it to be left.
   Richard: But oftentimes you want it to be the start of the line.
   Steve: A long time ago we decided not to relativize left/right/top/bottom.
          It's confusing if left did not mean left anymore.
   Richard: Maybe I don't mix up start and before because I've had to use
            those languages and I've had to learn what they mean.
   <anne> (I was suggesting something like :root > main { float:left }
          :root:dir(rtl) > main { float:right })
   David: I'd note that our localizers are the ones who care about this. And
          when I start up the Hebrew version of Firefox, I get this.
   David: The localizers will go through the theme style sheets to make sure
          that the style sheets use the correct relative keywords
   David shows a copy of Firefox whose UI looks mirrored from the English layout
   Bert: Is see that you really have to think about it when you write the style
         sheet. It's not automatic whether it's left/right or start/end
   some argument about how much thinking happens when deciding which keyword
     to pick
   David explains to howcome that Mozilla has implemented start/end
     *-start/*-end internally
   <br type="lunch">
   <anne> type is not a valid attribute for br people
   <Bert> </br>
   <anne> that's invalid too in HTML
   <anne> (in fact, it would get parsed as <br>, which would mean another
          break, which works for me...)

Vertical text and CSS3 Text Layout

   Alex: We waited for Beta2 to come out before we started talking about
         implementing vertical writing for Mongolian etc..
   Alex: We have support for all eight text directions
   Alex: We want that to be compatible with Text Layout spec
   Alex: What we propose to do to Text Layout spec is two things
   Alex; one we want to separate that
   Alex: Currently there is vertical writing mode part
   Alex: And there is a separate part about document character grid
   Alex: We think that the text layout part of it is very well defined and
         appears to be complete
   Alex: We propose to make that a separate spec and quickly bring it to
   Alex: For line grid and document grid, we are not sure how to define
   Alex: Because we don't have a requirements document.
   Alex: We can't say whether this is complete or not complete. That
         should be a separate spec
   Alex: We have a partial implementation of that as well, but we don't
         think that can move to REC as fast.
   Alex: So we propose to separate that out and move it to low priority
   Alex: but move vertical text to CR asap
   Alex: The last thing that we want to do there is to add bottom-to-top
         writing mode
   Alex: so that we have all eight directions.
   Alex: I think we want to add it just because it is very well-defined
         what it does.
   Alex: Use cases are marginal, but we don't see why we should undefine
         that when it is totally clear what it means.
   Alex: I'm fine with making that optional
   Alex: That's alll.
   Alex: Once you've got Mongolian, you've got the hard part done.
   Alex: Because in Mongolian your line bottom and paragraph bottom don't
   Elika: So that sounds pretty good.
   Elika: I say to take the vertical writing mode controls and combine
          them with the definitions from the Box Module
   Elika: And make that a spec
   Elika: Because the writing mode definitions are not enough to say how
          the new orientation maps to the calculations in CSS2.1 Chapter 10
   Elika: And how nested differing writing modes interact
Scribe: dbaron
   Bert: But good thing about making text layout a CR is that it stabilizes
         the property names.
   Steve: So there's no objection to splitting out a piece of the text layout
   ACTION: fantasai set up redirects
   (side discussion about publishing documents in dev space vs. group space)
   Elika: You didn't implement glyph-orientation or ? properties?
   Alex: right
   Alex: they're not in the spec anymore

   Elika: I'd like to define terminology so that other specs can refer to
          terminology rather than referring to values of specific properties.
   Bert: depends on context
   Richard is frustrated because can't ever be sure he's reviewing the right
            document because he can't always find the latest documents
   Elika: I think we do have agreement on the part MS has implemented.
   Elika: So I think direction, writing-mode, and block-progression should go
          in the trimmed box-model.
   ACTION: Bert work out what is missing from Box Module and ask dbaron for it
   Elika: spec should describe how vertical text works
   Alex: I worry about describing completely.  Vertical text alone isn't hard;
         orthogonal flows are hard.
   Elika: Whether block-progression should have a prefix in IE depends only
          on syntax, since its behavior is already derived from writing-mode,
          and writing-mode is implemented un-prefixed for years.
   Peter: If we merge things into other modules, I want to avoid blocking
          those modules for lack of implementation.
   Saloni: Not really happy about moving from one draft to another -- want
           to progress it.
   Elika: We can't progress without definitions.
   Elika: Best is to review Bert's draft.  Make sure it's consistent with
          what you're implementing and with CSS 2.1, then we can publish CR.
   Saloni: We're willing to put in work to progress this part.
Scribe: fantasai
   David: Can we avoid discussing how we split the modules until after those
          parts of the specs are CR-ready?
   David: Because we keep switching what parts of the Box Module and Text
          Module should be together
   Steve: So there are some parts of specs that are closely tied together
   Steve: We could put the relevant bits of the Text Layout module in the
          Box Module
   Steve: Or put the relevant bits of the Box Model into the Text Layout module
   Steve: Or develop two modules, one Box Model Basic and one Text Layout Basic
   Steve: I prefer the last option, as the easiest way to make progress.
   Elika: That works for me. I just want to make sure we have the box module
          definitions and the syntax, not just one or the other
   Elika: Because they are both needed for a complete dfinition of vertical text
Scribe: dbaron
   Saloni: So what we're doing is pulling out 'writing-mode', ...
   Saloni: ... into text layout basic module, and put in details and behavior
   Elika: But also look at box module
   Alex: ... and help Bert with parts of box model.
   Alex: And then work on test cases corresponding to current state of both
   Elika: If ready for CR tomorrow, we could pull stuff out of box model and
          move to CR.
   RESOLVED: Make writing mode part of Text Layout into an independent spec
   ACTION: fantasai make that split and inform Bert
   <alexmog> link to text layout draft: http://dev.w3.org/csswg/css3-text-layout/
Scribe: fantasai
   Steve: Someone should contact Murakami-san and point out what we're doing
          here and ask him whether they might have an implementation
   Richard: We should also inform the JLTF
   ACTION: Steve contact Murakami-san and JLTF about relevant developments here
   <plh> http://dev.w3.org/ was (still is) having troubles this morning. It
         has been reported but I'm fearing our system folks in the US didn't
         see that yet :(
   Steve: Bert, are you willing to split the Box Model again?
   <Bert> (Yes, dev.w3.org is extremely slow since a couple of hours, sys
          team knows, but doesn't seem to know why yet.)
   Bert: Yes, but I'm having trouble making sure I don't lose anything everytime
         it splits and recombines :)

   Alex: There's also a Ruby spec which could follow the same track.
   Alex: I'm less concerned about that
   Alex: As we only have partial implementation of Ruby spec
   Elika: We don't have an editor for that right now
   Anne: There are also some open ruby issues
   Alex: I wanted to mention that, but we don't have any current plans to
         advance that
   John: We have two developers in Japan (for Mozilla) who want to implement
         it, but say the spec is dodgy
   Anne: The markup subset that IE supports and is part of HTML5 is not really
         good at handling complex ruby
   Richard: It doesn't handle complex ruby
   <anne> ( http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html#the-ruby )

   Steve: one last question, Paul, fantasai, and I proposed a text-orientation
          property that has a partial description
   Steve: Clearly not implemented by MS, but..
   Steve: We recognized that glyph-orientation is not what you want for a lot
          of cases
   Steve: Since you want to operate on runs of text, not on glyphs
   Steve: The simple thing is to take text and rotate it right.
   Steve: which is what IE does
   Steve: you want some way of controlling that, but glyph-orientation is not
          the right way to do that kind of thing
   STeve: If you're going beyond the default behavior here then we want to
          consider text-orientation
   <dsinger> sorry, you are rotating the glyphs and leaving the writing
             direction, or rotating the baselines (the bounding box and all)?
   Elika: So we should keep text-orientation with the writing-mode definition
   ELika: And just have the two values we really need, 'right' (the default,
          what IE has implemented) and 'upright'
   Elika: We should be able to take that to CR.
   Elika: Leave the complicated values like invert etc. for later
   Elika: er.. actually the default was 'auto' which iwas do what
          glyph-orientation says if you implement that, otherwise do 'right'...

Vertical Layout Terminology

Scribe: dbaron
   Elika: I think we need agreed-upon term for defining writing modes,
          directions, etc., for when we're writing our specs.
   Elika: Avoid having to write out property-value pairs everywhere in
          definitions, and makes it easier to expand functionality in the
          future without doing as much editing.
   Elika: I want to go over some concepts and pick the names for them.
          I volunteer to write a note that will define them so we can
          refer to them easily.
   Elika: Also, we need to define start, end, before, after, etc., and
          lock down on names for writing-mode-related properties.
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Feb/0294.html
   Elika: Paul, Steve, and I discussed in February and came up with names.
   (discussion of logical width / logical height)
   Bert: for the box model, I don't need those
   David: you could use * length, e.g., "block length" and "inline length"
   Bert: I need a term for the margins that collapse (top and bottom in
   Elika: Depending on how you're writing the specs, you might want or not
          want some of these.
   Bert: I also want terms for rightwards, etc.
   Alex, Saloni: We used logical width, logical height, logical left, etc.
   RESOLVED: Dimensions use logical width & logical height, (physical)
             width & (physical) height
   David: Does "inline direction" mean "rightwards" or "horizontally"?
   Elika: rightwards
   Steve: It's the direction in which you add characters on the line
   David: dimension, direction, axis
   Bert: I want a concept to refer to the left/right vs. top/bottom
   Steve: direction is always an arrow
   Steve: dimension is always a measure
   Elika: (presents "Layout Modes" section of above)
   Bert: sometimes I couldn't use "in vertical mode" because it mattered
         whether block direction was leftwards or rightwards.
   <fantasai> "in top-to-bottom writing mode", "in left-to-right writing
              mode", "in right-to-left writing mode"
   <fantasai> Richard: "in bottom-to-top writing mode"
   <dsinger> block progression and inline progression are the two usual
             terms, no?
   <dsinger> (going offline imminently)...
   <dbaron> I don't like using the term "writing mode" such that
            "top-to-bottom writing mode" and "horizontal writing mode"
            mean the same thing.
   (lots of discussion)
   Saloni: Saying things like lr-* or *-tb worked well for us.
   Elika: "rl block direction"?
   Elika: We could adopt convention of "RL block direction" being uppercase
   * plh thinks the Group is getting tired :)
   (discussion of "progression" vs. "direction" vs. "progression direction")
   Elika: (presents "Sides" section of document above)
   Elika: people sometimes find before and after confusing
   David: where "before" is ambiguous you can say "before-edge"
   Elika: we also want these in "float: start", "margin-start", etc.
   Elika: We're probably stuck with these for some cases.
   Steve: Can I propose we use before and after unless someone comes with
          something better.
   Håkon: OK in specs, but I don't want to allow these in values or properties.
   Håkon: It's a disaster for float.
   <glazou> <br style="pause: 900s"/>
   <fantasai> Notes from break: proposals for replacing before/after include fore/aft and head/tail

Roadmap for Completion of CSS2.1

Scribe: fantasai
   arronei joins via phone+irc
   Peter: We need a plan for finishing CSS2.1
   Peter: main focus is getting test suite complete
   Peter: where are we?
   Arron: From our side we just released another 3000 tests roughly
   Arron: I'm going to start submitting those in the next couple of weeks
   Arron: You guys discussed the review process yesterday, Elika and I will
          work on getting the submission process working
   Peter: I saw yesterday a nice map of how the test suite should be broken down
   Peter: Do we have a map of what's being submitted and what's being worked on?
   Arron: I can explain what we're doing
   Arron: and where we're heading.
   Arron: Might take me a week to pull that all together
   Peter: Mozilla was going to submitting tests?
   David: I have some tests. I have to figure out what to do with them
   David: I have a few tests for some Chapter 10 stuff
   David: I had some counters tests that I submitted long ago and are in the
          test suite now
   David: I might be able to dig up some others
   peter: My main concern, my goal is to get some timeframe on this
   Peter: progress with some concrete milestones
   Peter: What information do we have, what can we expect
   Philippe: What's the goal of the test suite?
   David: There are two
   Peter: One is to measure conformance once we have a REC
   Peter: First is demonstrate sufficient implementations to get to REC
   David: Other one is to actually improve interoperability of CSS
   Elika: When the test suite is complete enough for us to move to REC, we
          will take a snapshot and get implementation reports
   Elika: We will continue to accept tests to increase coverage and drive
   Peter: What's the measure for complete enough?
   Philippe: Depends on the group, it's purely subjective
   Steve: One piece is not subjective
   Steve: Intended that all features be tested
   Steve: Now what is a feature is subjective
   Steve: but at least if the director asks "what is a feature", you need
          an answer
   Daniel: You need at least one test per property-value combination
   * melinda thinks you need one test per 'testable assertion'.
   Elika: I think that once Microsoft has submitted all their tests, since
          they are writing a test for every property-value combination and
          every "rule" in the test
   Elika: We will have a good baseline level of coverage of the spec
   Elika: Add to that the more complex tests from Mozilla and Hixie
   Elika: I think we will have a pretty good level of coverage for progressing
          to REC
   Elika: At that point we should take a look, see if we have any obvious
          holes, plug them, and then take a snapshot and use that.
   * Bert (re Melinda): but if the statement is "for all elements satisfying X,
          do Y," that's one statement, but many tests.
   <melinda> Exactly.
   Peter: Were discussing making a task force for reviewing the tests
   Arron: It sounds risky for the task force to do the review.
   Arron: It would be better to have more of the task force to do a cursory
          review to see that it isn't blatantly wrong
   Arron: And have a few people do the final review
   peter: I'm not sure if that's a good idea to have a few people review,
          because that becomes a bottleneck
   Arron: We have currently four people who can do reviews
   Elika: One problem is that we don't have a list of which tests need review
   Elika: I can't say, come help review
   <melinda> The problem is they're all real busy folks
Scribe: Bert
   Elika: There are too few people qualified to do reviews right now
   Peter: Use the test harness and see what tests get inconsistent results.
   Peter: Those tests need review.
   Peter: Maybe flag tests in suite that are not stable
   <melinda> It's more that you need to ensure the test is really testing
             what it purports to be testing.
   Plh: Different kinds of test suites, full suite for interoperability.
   Plh: Danger is if a test is in the test suite and is incorrent, people
        think the test *defines* the behavior.
   Elika: People can always submit tests that show incompatibilities.
   Plh: Test that test multiple properties at same time?
   Daniel: Many cases where properties are correlated. Need to be tested.
   Plh: Can I submit Acid3 as a test.
   Several: Too many parts that don't apply to CSS.
   David: If you remove those parts, you're left with nothing.
   David: But someeparts of it can be pruned into a good test.
   <anne> (and from Opera!)
   Howcome: But still good to have it included.
   Elika: We need more review and system that makes it easy to review.
   David: Who are the reviewers right now?
   Elika: Anne, Hixie, Elika and David. Latter two most active and David
          less than Elika.
   Elika: Can get other person from MS to review. I don't know those
          people enough.
   Elika: Need to see Arron's work first, then I can say what he can review.
   Elika: I don't care about who is from what company.
   Elika: I'm not reviwing all 3000 or so tests, but review a sample, and
          then trust him on the rest.
   Elika: Already three people seeing all tests anyway at Microsoft
   Peter: When can we expect rest of tests from MS?
   Alex: Will keep working on them, Cannot say exactly.
   Alex: We are still developing new tests.
   Plh: A deadline until when to accept tests?
   Peter: A target date, but we may not have enough by then. End of year?
   Elika: End of year is good target for a review of where we're at
   <melinda> When MS submits their tests, what % coverage do we expect we'll
   Arron: Agreed. Check again at 1st meeting in January.
   Plh: is it reasonable time for Moz as well?
   David: Sure...
   Peter: Once we have a reasonably complete set, ready for review, can we
          set a regular review target, maybe 25% every quarter?
   Elika: Possible.
   Plh: Is the format frozen.
   Elika: yes.
   Alex: Anybody can review. Give a 100 to each of us in this room.
   <melinda> Why wait until we have a complete set to set review targets?
   Elika: We've been working on a process, with initial and final review.
   Elika: Final review looks at comments from initial review.
   Alex: use public mailing list for initial review?
   Elika: We do it, but not ideal.
   Elika: People not yet on the list don't have the history.
   Peter: Do we have plan for building a system?
   Peter: Document management-like system. HP donated server to host repository.
   Peter: We are starting to implement. Would like help.
   Plh: Let people test with experimental suite and look at problems.
   Elika: That doesn't tell you if the test tests what it says it tests.
   Elika: If a test fails, we need to look at it. If a test fails sometimes,
          we need to check that too. But that is only part of the work.
   Plh: We should tell people to look at the source if a test fails.
   Plh: Nothing will be perfect. Things fall thrugh the cracks always.
   Plh: I guess many CSS authors will be happy to help.
   Elika: I want to get more involvement, volunteers and companies.
   Elika: A transparent system, easy to submit and report.
   Elika: Even if somebody cannot do final review, sending comments is
          still helpul.
   Plh: Can also organize an event where people comm together with their
        laptops and run the tests together.
   Elika: Or something like Mozilla's bug days on IRC, but where people
          write tests.
   Peter: We can spend part of our ftf for that if we're not getting
          enough traction

Republishing CSS2.1

   Arron: How about publishing another CSS 2.1 draft?
   Peter: I think so.
   Elika: When we reach 0 on issues list, we can publish a WD.
   Elika: Cannot be CR, because of substantial changes.
   Elika: We have an errata list, but many people who read the spec forget
          to read the errata.
   Plh: Substantial changes need WD, yes, but substantial is a subjective term.
   Plh: Can say in last call where you made changes and set expectations
        for comments.
   Steve: Still takes time.
   David: Want to avoid WD. People send lot of comments.
   Discussion about shortest last call period.
   Steve: Can say that we take comments on unchanged parts and will reconsider
          them for level 3.
   Steve: If we say it explicitly up front, we have more arguments to reject
   Discussion about how many comments expected. Hundreds?
   bert: Like to avoid moving back to WD.
   Steve: If changes modify an implementation, it's difficult to do them in
          a next version.
   Peter: don't want a CSS 2.2.
   Anne: Let's get test suite first, before we publish anything.
   Elika: Definitely need a new WD before PR.
   Elika: Question is when.
   Plh: Then how do you help people who miss the errata?
   Anne: We can have public editor's draft.
   Bert/Daniel: Those have no status.
   Peter: that can help us postpone republishing.
   Daniel: We are not helping people to understand what status of W3C
           documents is.
   Daniel: People see a document from the WG, from the W3C, don't understand
           how to interpret it.
   David: The document with the errata integrated is useful for me as an
   Peter: Public ED draft helps public to see progress.
   Steve: Don't get much comments on public ED drafts.
   Anne: I've had many comments.
   David: Also OK with publishing on /TR, but it uses up resources.
   Bert: Pb with going to WD is (1) image problem, we're moving *backwards*,
         and (2) have to go to CR again.
   Plh: Short last call has been done, is possible.
   <melinda> What changes have we made that can't be classed as 'minor
   Steve: If CR leads to questions about rejected comments, can point
          to why they are rejected.
   Plh: Let people know that maintenance is going on?
   Steve: The CSS2 Rec has a not pointing forward to CSS 2.1.
   Plh: Publish a CR and say in it that there will be a WD before PR?
   Steve: Not possible in process.
   Daniel: Editor's draft gives impression that we don't want to follow
           the process.
   David: The process doesn't allow us to work the way we work. Process
          needs to change. We make incremnetal changes.
   Steve: Incremental changes, yes, up to the release date.
   David: This group essentially tries to reach perfection before we ship.
   Daniel: I've said that many times.
   David: We've essentially said we are never going to ship.
   Daniel: David, you're one of the people wanting perfection...
   David: We've said everything will go into CSS3, so we're not going to
          change CSS2 anymore.
   Steve: Cannot publish errata. They have to be incorportated (eventually).
   Plh: "Edited Recommendation"
   Daniel: That's what we need.
   David: If we already had a test suite and already were in Rec, we could
          use PER, but we're not there yest and have to go through heavier
   Elika: We have spec and implementations, not tests yet.
   <fantasai> Straw Poll: Do nothing, publish Editor's Draft (with note
              about expectations), publish LC/CR
   <molly> Wait
   <molly> this conversation has been completely confusing.
   * Bert is not surprised :-)
   <molly> can someone please put into lay terms exactly what benefits/
           deteriments each of those choices offer?
   <fantasai> So, this is wrt CSS2.1 for which we have a lot of errata
   * anne wants an option for moving the editing process to dev.w3.org
   * anne would vote for that
   <Bert> LC/CR will be when test suite is complete.
   <fantasai> but the errata aren't incorporated into a public copy of CSS2.1
   <fantasai> just the internal copy
   <fantasai> LC/CR has a lot of overhead
   <Bert> Public editor's draft is regular, starting now.
   <fantasai> Editor's Draft is unofficial
   Howcome: no opinion
   Elika: Editor's draft
   David: Editor's draft
   Daniel: Do nothing
   Saloni: Editor's draft
   John: Editor's draft
   Steve: Editor's draft
   Peter: Editor's draft
   Alex: Editor's draft
   Bert: Do nothing
   * molly whatever moves CSS 2.1 forward
   Anne: Editor's draft
   Arron: Editor's draft
   <glazou> molly, that's the problem... forward according to us,
            to users, to W3C Process
   RESOLUTION: Publish Editor's draft periodically
   <anne> (for the record, I want editing to happen in public, either by porting
           the script, or comitting to dev.w3.org automatically or something)
   * myakura wondering why not publishing another css-beijing wd, incorporating
             that note
   * fantasai what note
   * fantasai a note wouldn't solve the problem of people forgetting to check
              the errata when they look things up in the spec
   <myakura> the one about expectations
   * fantasai ah
   RESOLUTION: Add note to Editor's draft about expectations for future publications
               i.e. expectation to publish LC/PR once test suite is done
   * melinda thinks it would be worthwhile identifying just which changes we think
             exceed 'clarifications' and 'minor corrections'

CSS3 Fonts

Scribe: fantasai
   <jdaggett> http://people.mozilla.org/~jdaggett/css3fontspresentation.pdf
   John: The CSS3 Fonts spec I'm editing is based on the CSS2.1 spec with
         some additions
   John: It combines the two CSS3 Fonts and Web Fonts sepcs
   John: It's still an editor's draft.
   John: server is flaky today
   John: Slides posted to IRC
   John: Tried to add more informative typogrpahy info
   John: A lot of i18n things that a lot of people wouldn't be familiar with
   john: Planning to add a note about how some of this relates to TrueType data
   John: My goal is to iron out the @font-face definition
   John: and then add more features
   John: The themes are, mechanics of @font-face
   John: font-matching algo improvments, enabling richer typography, and
         text-rendering effects
   John: Fonts Today
   John: Covering where tech is today vs 10 years ago
   John: Fonts are much richer today
   John: Underlying platform APIs are much more complex
   John: You have things like Uniscribe, Pango, CoreText
   John: Far wider variety of scripts to be handled
   John shows some examples of different scripts e.g. diacritics, cyrillic,
        Arabic shaping, Linear B which is written with surrogate pairs,
        MathML which needs specialized fonts
   John: Evolution of True Type
   John: Started as Apple format, it's a container format
   John: early TrueType was scalable glyphs with quadratic splines
   John: ...
   John: Around early 90s, Apple developed TrueType GX
   John: The extended TrueType by adding more tables
   John: Added support for richer typographic variations and allows
         handling of complex scripts
   JohN: but not shared with MS
   John: So Microsoft creates TrueType Open
   John: Adds tables
   John: created OpenType with Adobe
   John: Created two glyph formats, quadratic (.ttf) and cubic (.otf)
   John: Apple changes TrueType GX name to AAT
   John: Problems with TrueType
   John: dual platform nature -- there are platform-specific data in the fonts
   John: e.g. family names are per-platform
   John: And font classification is different
   John: Usually font vendor tries to make them match, but errors arise
   John: e.g. weight is pulled from OS/2 table on Microsoft, Apple based on
         style name
   John: Complex script handling is completely different
   John: Apple is slowly adopting OpenType, so this difference will go away
         in the future but right now that's how it works
   Some confusion about what formats are being discussed atm
   John summarizes data in the TureType Name Table
   Fmily, subfamily, full version, license
   John: for each name, there are two platform names, n localizations
   John: differnet style names for each weight
   Style Linking
   John: different processes for unifying a set of faces into a single font
   John: Apple says to use the same family name across all style variations
   John: Microsoft spec restricts family name to only regular, bold, italic,
         bold italic
   John: Has a "preferred family name" to group a larger set
   John: "Savvy" apps use Preferred Family, then Family
   John shows example of names for Kozuka Gothic Pro
   On Macintosh you see one family with 6 weights
   on Windows you see 6 families, 1 weight each
   "savvy" apps can use the preferred family name
   John: Browsers need to become "savvy" apps on Windows
   John: How to map "old-style" family names?
   John: Luckily very few in actual use on web
   John: But because of this, lots of spec bugs hidden by lack of style-linked
   John: Discussion yesterday of bolder vs lighter is an example of that:
         problem because people don't usually see more than two weights
   John links to some further reading material
   John: Interesting point, Microsoft has come up with their own version of
   John: They do a lot of synthetic faces, etc.
   Philippe: W3C is trying to set up group to do EOT. How does that effect this?
   Steve: Don't ask that now.
   John: So this is the font-matching algorithm for CSS2.1
   John: You match the family name to a set of font faces
   John: Match font-style, fallback on failure
   John: Match font-variant, fallback if not synthesized (archaic)
   John: In the past, e.g. smallcaps was a separate font. These days it's
         incorporated, so you don't need this
   John: ....
   John: Because of the way font-style is matched, font-style trumps
         font-family in the spec
   John: Reality is most user agents either synthesize italic
   John: or ignore it
   John: if they don't find italic
   <anne> (I don't understand why smallcaps being incorperated obsoletes
          the need for font-variant...)
   <anne> (Idea: make a small-caps variant or something for Ahem, to test
          this easily)
   discussion about small-caps
   <Bert> (Would be called "Ahem Pro" then :-) )
   Howcome: on the small-caps issue, shouldn't that still be part of the
            font-matching? Because if you specified small-caps you want
   Several people: you synthesize it
   John: Many scripts have no concept of italics
   John: in CSS3, suggest no fallback on italic, and no matching of font-variant
   Howcome: What do you suggest should happen if there's no italic
   John: dont' fallback on italic
   John: say italic and oblique are equvalent unless both faces exist
   Howcome: but then you synthesize it. Then I'm ok with it.
   Peter: you might want a soft fallback
   Peter: e.g. if there's an italic in the list, then fall back to it
   Peter: if you fall back to the system font, then go back to the front
          and use synthesis
   Jason: So if you specify italic, you fallback to oblique?
   Peter: No, I'm saying that if you have a list of three fonts and your
          first font doesn't have an italic, but the second one does
   Peter: then you use the second one
   Peter: but if none of them have italic, then you go back to the first
          one and synthesize it
   Jason: The author usually expect that you'd use one font throughout the spec
   Steve: that's not true because the choice of fonts is on a per-character
          basis in CSS.
   John: Currently all browsers just synthesize an italic
   Peter: Rather than synthesize an italic font, wouldn't it be better to
          fall back to another font that's specified that has an italic?
   Ishida: In Cyrillic some italic shapes are radically different from
   John: That's not unique to Cyrillic. There are fonts where that's true
         in Latin
   John: Another problem in the spec is that italic and oblique are treated
         as if they can exist in the same font-family
   John: And they almost never do
   Bert: the case where these are different are Knuth's fonts
   Bert: he uses them to mean different things
   John: It's a very rare case
   John: I want to clean up the archaic stuff in this spec
   fantasai: I think Peter's double-fallback proposal is good to consider
   <anne> (Can Ahem Pro do italic and obligue fancyness? Maybe we need several
          different Ahem Pro's to test accurately...)
   Jason: One thing that I suggest is, Iknow from experience that most serious
          typographers would rather rip their arm off than have the UA
          synthesize an italic or oblique font
   Jason: So I think we should have a way for italic to fall back to normal
   John: I think it would make more sense for those typographers to use web
   Jason: until then
   Peter: or if that doesn't work for whatever reason
   John: So I propose a simplified Web Fonts definition
   <Bert> (Web Fonts allow you to specify a specific font for italic, it
          doesn't actually have to be an italic font.)
   John: Trimmed down version of CSS2 @font-face spec
   font-family, src url, src local
   font attribute descriptors (font-weight, font style etc)
   unicode-range for combining fonts
   no attribute-based font substitution
   Safari already implements this, Moz and Opera coming soon
   John: I took font-variant out because it's a rendering-time thing, not a
         font-selection thing
   John: You don't need it for descriptors
   Bert: So I can't say I want to use this font for small-caps, I want it
         to be the same as for roman
   John: All the fonts are going to store that in the same font file, not a
         different one
   Bert: I don't care where it's stored
   * glazou wonders if all your fonts are belong to us
   Bert: you're making it impossible to use the Computer Modern fonts
   Bert: I'm concerned about every case where my roman doesn't have smallcaps
   Bert: And I want to tell the browser where to find the smallcaps font
   Steve: So let's go back and understand where the web font descripters are
          there for
   John: Motivations
   John: We want richer set of available fonts
   John: Much tigher control over how content is rendered
   John: Better support for international sites (e.g. BBC)
   John: Domains with specialized font requirements sucha s MathML
   John: Also allows us to improve integration of SVG fonts in HTML content
   John: Need for restricted font formats is a separate discussion
   John shows css3-fonts spec
   John: This is an example using Gentium
   John: The UA is using Gentium to render the text, but if for some reason
         the font is unavailable the serif font will be used
   John: If Gentium is on the system, this rule will not use any fonts that
         are in the system
   John: The reason you want to do that is that if you don't, you run into
         the situation where some user has the font that you're using
   John: and not the font you want them to use
   John: It is possible to set this up a different way
   John: src: local(Gentium), url(/fonts/Gentium.ttf); will look for Gentium
         on the local system first
   John: I originally wrote the spec the opposite way.
   Howcome: I agree it's not clear which is the best
   Howcome: But I'm leaning towards what you had in there first.
   John: Then how do you turn that off, so that it's always downloaded?
   Steve: Add a keyword like 'download'
   Peter, Steve: Note the default behavior will always be to use the local
   David: The other possibility ..
   David: You say that if local() is not in the list, then you assume it's
          at the beginning of the list
   David: but if it is in the list, then you use its position at that location
   David: That way if the author wants to say the local version is the lowest
          priority, then he has to specify it as lower priority. Otherwise
          it's implied at the front of the list.
   Some arguing
   fantasai: I don't think we should be wasting bandwidth by default
   Steve: I think the behavior on down-level clients should be the default
   Steve: down-level clients will always use the local copy if it exists
   John shows last example of combining local() to make a shortcut for
     family names
   John shows example of pulling out a font that otherwise would be
        inaccessible using CSS

   John shows some examples of unicode-range
   John: back to Steve's question
   John: What do descriptors do?
   John: Do descriptors define underlying attributes? or are they hints of
         what's in the font?
   John: Problem is, if descriptor says the font-weight is bold but font
         says it's not what happens?
   John: I think this is really confusing
   John: I think the font-descriptor should override whatever's in the font
   Steve: The notion of descriptors came from the idea that you build a table
          of fonts
   Steve: with their attributes
   Steve: the role of the descriptors was to build this table without having
          to download the fonts
   John shows an example of two statements that use the same font name
   Howcome, Bert: the assumption is that you assume both statements have all
   * fantasai is not following this discussion
   Steve: So the question is, how does that table get built if I have multiple
          font declarations that have overlapping definitions
   Steve: My understanding is that I build my table
   Steve: For the first declaration, I populate all 18 slots in my table
          (all weights and styles) with Bongo
   Steve: pointing to that src
   Steve: The second declaration updates the italic entries to point to the
          second src
   Steve: Most fonts today don't have all weights in the same file
   Steve and John to talk offline
   <dbaron> As far as I can tell, CSS2 was ambiguous about whether the
            descriptors override the font data.
   <Bert> Question was what is most useful default for a descriptor: all,
          or normal?)

   John: Security Issues
   John: There's a definite potential for intentionally corrupted fonts to
         become an attack vendor.
   John: Errors can occur with metrics, at drawing, etc.
   John: You can do some validation, but not that much
   Howcome: This is just battle-testing the font renderers. It's something
            they have to go through.
   John: Note that fonts associated with one page should not affect rendering
         of another page.
   John: Also you don't want to use downloaded fonts in a system fallback.
   Howcome: if both pages point to the same src for the font, what then?
   David: follow the HTTP cache headers
   John: Last thing, Thank You to WebKit!
   John: Their code sends a previously-secret special parameter that's
         necessary to implement this :)

   John: Size Adjustments
   John: We reworked the description of font-size adjust
   John: Tried to improve the explanation, not give a long list of aspect
   David: I wrote an explanation of it as well on MDC, you might be
          interested in looking at it
   John shows an image from the spec that explains font-size adjust
   David: I hope this draft incorporated the CSS2 errata on font-size-adjust
   David: It was dropped from CSS2.1, but we did make some corrections to it
   Ishida: I have some real problems with Arabic etc.
   John: Ok, yes I will say that this is very Western-centric.
   John: There are definitely problems with rendering Latin with CJK
   Steve wants to say why he really wants this to work with Arabic
         but will wait til later
   John: Beyond X-height Adjustments
   John: Font-linking on CJK Windows..
   John: Certain fonts like Tahoma have magical properties
   John: that link to ther CJK fonts
   John: On a fallback to CJK, resizing occurs
   John: it will make the CJK characters bigger
   John shows a screenshot
   John: This is something that has been done for readability on Windows.
   John: We should think about it for CSS
   John: and whether it fits in with CSS
   John: and/or how to address its use-cases
   Alex: Michel Suignard would know all about this
   John: There are other situations where this type of size adjustment
         would be interesting

CSS3 Fonts: Extending font-variant

   John: Last thing I wanted to discuss is how to improve typographic features
   John: based on the idea of exposing OpenType features
   John: extending font-variant to support opentype features
   John: e.g. ligatures, figure forms,  other features
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2008Jan/0380.html
   John: I think the key here is picking out the features that are appropriate
         for a large audience, not necessarily all OpenType features
   John shows some examples of ligatures
   John shows some examples of digits
   monospace digits vs proportional digits
   monospaced digits are different glyphs, often used for tables
   John shows example of alternate glyphs in Japanese
   John: Lastly to wrap up, some rendering properties
   John: text-fill-color, text-stroke-color, text-stroke-width
   John: Need to think about how this works with SVG
   * fantasai notes that the minute-taker is tired and hungry :)
   <anne> ( http://www.urbandictionary.com/define.php?term=m(__)m )
   Ishida asks about language features in OpenType fonts
   Ishida: Does lang trigger the appropriate language features in the
           OpenType fonts?
   John: I haven't looked deeply into that
   more discussion of languages and features and mixed scripts

Meeting closed fwiw

<fantasai> molly: I got a question for you
<fantasai> there's a CSS property that changes the direction of block flow
<fantasai> For horizontal text it takes the value 'tb' (for top-to-bottom flow)
<fantasai> For vertical text it takes the values 'rl' and 'lr'.
<fantasai> Question is, what's a good name for it?
<fantasai> It's currently called 'block-progression'
<fantasai> other suggestions include 'block-direction'
<fantasai> what do you think?
<molly> sorry, I'm back now.
<molly> and for the record I want to be you when I grow up, Elika
<molly> my goodness, you're a powerhouse, woman!
<molly> so the actual normal flow changes within the block?
<fantasai> yeah
<fantasai> it changes direction
<molly> block-flow
<fantasai> sure?
<fantasai> I will bring that up tomorrow :)
<molly> well, I think it's the most clear.
<fantasai> cool
<fantasai> so
<molly> if the whole point is to change the flow of the block
<fantasai> block-flow: tb | lr | rl
<fantasai> ?
<molly> I think that makes sense
<fantasai> ok
<molly> what do you think?
<fantasai> Makes sense to me :)
<molly> hehe
<molly> isn't it the middle of the night there?
<molly> go to bed!
<fantasai> yep
<fantasai> hehehe
* fantasai updates a few more issues and then obeys molly :)
<molly> I wish I could be there with
<fantasai> I wish you could too
<fantasai> we have no web-designers present this meeting :(
<molly> alas, not this trip, I just couldn't physically do it
<fantasai> I'm sure you'd be bored out of your mind half the time
<molly> Well, I'll stick around online as close to things as possible.
<fantasai> but it's really helpful to be able to ask "what makes sense here
            from your perspective?"
<fantasai> yay~
<molly> absolutely, and it always makes me feel good to contribute *something*
         of value
<fantasai> :)
<molly> I am planning to be at TPAC so that'll be good
<fantasai> awesome
<fantasai> another question
<fantasai> relates to font-weights
<fantasai> if you have three nested spans
<molly> okay, I was around for part of that discussion earlier g/a
<fantasai> with the font weights 'bolder', 'bolder', and 'lighter'
<fantasai> but you only have two weights, normal and bold
<fantasai> is the innermost span bold or normal?
<molly> what's the rule look like?
<fantasai> (A related question: if given two nested spans 'bolder' and
            'lighter', should the inner span always be the same weight
            as outside the spans?)
<fantasai> the rule looks like
<fantasai> <span style="font-weight: bolder">
              <span style="font-weight: bolder">
                <span style="font-weight: lighter">Am I normal or bold?</span>
<molly> well, I might argue that the only span of relevance is that directly
         spanning the content, and therefore, in this case, "lighter"
<molly> all of the other spans are empty
<fantasai> oh, well they could have text in them :)
<fantasai> or they could be <div>s
<molly> also, what's the parent? It seems that in part this would be
         inheritance no?
<fantasai> the behavior would have to be the same
<fantasai> no, there's no inheritance
<fantasai> it's just "bolder" is a relative term
<fantasai> if you have a font with three weights
<fantasai> then the innermost span would be the same weight as the outermost
            span, bolder than the text outside the spans
<fantasai> but lighter than the text inside the middle span
<fantasai> normal weight
              <span style="font-weight: bolder"> bold weight
                <span style="font-weight: bolder"> extra-bold weight
                  <span style="font-weight: lighter"> bold weight</span>
<fantasai> like that
<molly> so it's relative to the immediate parent span?
<fantasai> yep
<molly> urgh
<fantasai> the question is, what happens if you only have two weights
<molly> I say it goes to normal
<molly> in some ways it feels like as the designer
<molly> I'd need a "clue" to say, okay, there's a breakdown in the relation
<molly> if the author is intending to have a lighter color
<fantasai> right, well
<molly> that should be explicit (I hate hate hate relative values btw)
<molly> for this very reason
<fantasai> it's defined as lighter than the parent
<fantasai> but the designer might be trying to get back to the middle value
<fantasai> if there were multiple weights (like 3 or 5) that's what happens
<fantasai> I don't know
<molly> it's confusing.
<molly> I don't know either. Definitely a question to ask Jason
<fantasai> we've got both kinds of implementations
<fantasai> k
<molly> that's of course what I figured :)
<fantasai> I think I did ask him
<fantasai> and he said it was a hard question :)
<molly> any relative value questions are hard
<molly> to me, anyway
<molly> relational math? Designers don't think that way, they just don't for
         the vast majority anyway
<fantasai> heh
<molly> designers say "I want it THIS dark"
<molly> and give it a specific value
<molly> seriously.
<fantasai> we have keywords for that
<fantasai> seriously.
<fantasai> :)
Received on Tuesday, 9 September 2008 01:56:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:12 GMT