- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 08 Sep 2008 18:55:56 -0700
- To: www-style@w3.org
Attendees:
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
GCPM
----
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' ?
(drawings)
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
spec.
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
cascade.
Scribe: fantasai
Daniel: You can transform the document in ways that cause further
transformations
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
drafts?
Yes
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
OpenType
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
descendants.
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
inheritance.
Steve: Should record: with the selector approach, you have the overlap
problem.
<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
document.
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
out.
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
fallback.
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
block.
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
completeness
Alex: For line grid and document grid, we are not sure how to define
completeness
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
match.
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
stuff?
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
there.
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
documents.
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
horizontal)
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
interoperability
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
have?
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
comments.
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
implementer.
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
corrections'?
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
process.
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
family
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
Implications?
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
families
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
font-matching
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
small-caps
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
non-italic
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
fonts
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
version
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
weights
* 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
values
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
previously
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>
</span>
</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>
</span>
</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
here
<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
here
<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 UTC