- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sat, 11 Jun 2011 01:05:40 +0900
- To: "www-style@w3.org" <www-style@w3.org>
Transitions
-----------
- Tab presented a proposal for dealing with shortcomings in the Transitions
spec. < insert url here when Tab gets around to posting it :| >
Ideographic Variants
--------------------
- RESOLVED: Send comment to Unicode on behalf of CSSWG requesting stronger
requirements for sharing IVSes across IVD collections, and
the creation of a mapping table among existing duplicate IVSes
(and any matching CJK compatiblity ideographs). See UTS#37.
http://www.unicode.org/reports/tr37/
- RESOLUTION: font fallback goes all the way to system fallback with the
IVS before repeating with base, will add a property to
switch between that and font-consistency-priority matching
CSS3 Text
---------
- Discussed Håkon's list of issues:
http://lists.w3.org/Archives/Public/www-style/2011May/0721.html
- RESOLVED: Change 'bikeshedding' (previously known as 'white-space-collapsing')
to 'text-space-collapse'.
- RESOLVED: Mark 'line-break: loose' at-risk
- Suggested to pull out codepoint lists from 'line-break' rules into an
appendix and make it clearer that 'line-break' doesn't affect non-CJK
codepoints except when the text is tagged as Chinese or Japanese.
- Discussed 'text-spacing' property and 'text-justify' property, assigned
many edits to the editors:
- Make text-justify table use numbers/'never' instead of dots.
- Add a footnote for the 'auto' column.
- Add examples of text-justify usage from the minutes.
- Make it clear that glyph substitution is neither required nor forbidden
- Fix spec so that lower priority adjustment includes earlier priorities
- Make punctuation justification priorities more clearly out-of-scope
- Make it clear that TeX-style cost-based distribution is allowed and
add an example with 'inter-word'
- Discussed 'text-transform' property, assigned many edits to the editors:
- Make a normative appendix with the order of all text operations
- Define Unicode Database fields used for <wide> decomposition
- Point more directly to Unicode case shifting algorithm
- Make small kana mapping table
- Remove note about font-variant-ruby (goes in ruby spec)
- Add note about @text-transform possibility for future additions
- RESOVLED: Drop 'hyphens: all' and switch properties currently marked
optional to at-risk.
- Discussed whether to rename 'word-wrap' to 'overflow-wrap'.
The name 'overflow-wrap' is a much better description of what it does,
but 'word-wrap' is already implemented across browsers (unprefixed).
This remains an open issue pending feedback from WebKit and Opera.
- RESOLVED: Drop 'text-outline' since the new spread argument to
'text-shadow' can handle it.
Other: Charter, Floats, Regions
-------------------------------
- RESOLUTION: List CSS 2.0 as maintenance, asterisk saying to be obsoleted asap
- RESOLVED: Make css3-floats module to bring together proposals for floats
and exclusions
- Discussed pagination and forced breaks across pages, regions, columns.
====== Full minutes below ======
Present:
David Baron (Mozilla)
Bert Bos (W3C)
John Daggett (Mozilla)
Daniel Davis (Opera)
Arron Eicholz (Microsoft, via IRC)
Elika Etemad (Invited Expert)
Sylvain Galineau (Microsoft)
Vincent Hardy (Adobe)
Koji Ishii (invited Expert)
Peter Linss (HP)
Nat McCully (Adobe)
Luke Macpherson (Google)
Alex Mogilevsky (Microsoft)
Shinyu Murakami (Antenna House)
Ted O'Connor (Apple)
Florian Rivoal (Opera)
Shunchi Seko (NTT)
Shane Stevens (Google)
Taro Yamamoto (Adobe)
Steve Zilles (Adobe)
<RRSAgent> logging to http://www.w3.org/2011/06/03-css-irc
Scribe: jdaggett
Transitions and Animations
--------------------------
TabAtkins: talking about new directions for anim and transitions
TabAtkins: current spec has limitations
TabAtkins: transitions are only state-to-state
TabAtkins: that's different from the animations spec
shans: i've been messing around with ideas in js
shans shows demo
TabAtkins: note the weird interactions when hovering
TabAtkins: want animations of all properties
TabAtkins: make @transition rule
TabAtkins: with over, from, to, and animation
TabAtkins: syntax is at-rule with selector to identify the elements
that the animation applies to
alexmog: shouldn't that be the other way around?
TabAtkins: current property is just simple syntax
TabAtkins: this is the advanced version
TabAtkins: we have some issues
<smfr> is there a url for what's being discussed?
TabAtkins: with complex animations, multiple states
<discussion of where to stick the files so smfr can see it>
jammering about www-archive
<smfr> green on black?
comic book ninjas
more mumbling
these folks need more coffee, much too slow
cmon, going at web speed, blah, blah, blah...
danield: there are just four states?
TabAtkins: ... talking about various states...
aw that's cute, screen sharing by pushing two pc's together
TabAtkins: talking about states
TabAtkins: back to the button example
TabAtkins: number of states you go through
TabAtkins: going through a to c you can still go through b
florian: will non-defined paths be synthesized?
TabAtkins: normal transition is just a jump
TabAtkins: should be able to synthesize
TabAtkins: it runs a shortest path algorithm on the graph
TabAtkins: discussing missing legs
TabAtkins: describes how the path graph is defined
TabAtkins: wanted something that tells you what to do going between two states
TabAtkins: similar to the data attributes in html
TabAtkins: we can define a state family
TabAtkins: should be able to define keyframe animations over transitions
TabAtkins: everybody wanted something less weird but doesn't work
TabAtkins: showing same example with condensed syntax
<shans> @transition-graph #animateMe {
over: state-path;
@edge(A, B) {
animation: transition(left, top, background-color, -webkit-border-radius, color) 0.5s;
direction: both;
}
@edge(B, C) {
animation: transition(left, top, background-color, -webkit-border-radius, color) 1.0s;
direction: both;
}
}
sylvaing: hmmm, complicated...
vhardy: why "state path" and not the property?
TabAtkins: doesn't work well when defining multiple animations
<sylvaing> wondering about the wisdom of overloading attribute selectors
TabAtkins: problem of additive properties
dbaron: need to adjust the way the cascade to fix
dbaron: why should these be properties at all
dbaron: rather than something that you match with selectors
TabAtkins: working with selectors is hard to define
dbaron: work selectors and declarations within the at-rule
dbaron: put the selectors into the @transition-graph rule
dbaron: then the cascade just works things out
dbaron and TabAtkins discussing alternate syntax
vhardy: seems to me you're defining a graph
vhardy: the edges seem to be between paths which feels weird
TabAtkins: we have a state called path
chrome guys confess to abusing the use of 'path'
TabAtkins: showing an even more complex example because complexity is my
middle name
TabAtkins: showing click-animate-click-animate-click-animate
TabAtkins: you don't associate state with styles that apply to that state
<shans> @transition-graph #animateMe {
over: state-path;
@edge(A, B) {
animation: transition(left, top) 0.5s;
}
@edge(B, C) {
animation: transition(left, top) 1.0s;
}
@edge(C, D) {
animation: transition(left, top) 1.0s;
}
@edge(D, A) {
animation: transition(left, top) 1.0s;
}
}
TabAtkins: multiple selectors could set the state to D
TabAtkins: not sure what the correct answer is here
TabAtkins: these are useful for UI's
TabAtkins: people are trying to do complex things
TabAtkins: this is simpler for those cases
dbaron: weird that property values defined in one place and transitions
in another place
<smfr> i agree with dbaron
dbaron: should be more like keyframes
TabAtkins: defined by mixins
TabAtkins shows example using @node
<shans> @transition-graph #animateMe {
over: state-path;
@edge(A, B) {
animation: transition(left, top) 0.5s;
}
@edge(B, C) {
animation: transition(left, top) 1.0s;
}
@edge(C, D) {
animation: transition(left, top) 1.0s;
}
@edge(D, A) {
animation: transition(left, top) 1.0s;
}
@node(D) properties-for-D;
}
TabAtkins: this creates a property bag in the transition graph
TabAtkins shows demo passing through D node
TabAtkins: this gives us a unified model
TabAtkins: there are some issues
TabAtkins: fertile ground
smfr: tricky to talk about this in F2f format
TabAtkins: will post examples to wiki
vhardy: should we do this with the FX task force
TabAtkins: not doing anything incompatible yet
vhardy talking about state transition model
vhardy: lots of animation models when include things like SMIL
vhardy: i'm interested if we can more of the timing model of SMIL
vhardy: sophisticated effects require better sync
TabAtkins: we've thought about this a lot
TabAtkins: we probably don't want to go too crazy in css
TabAtkins: complex stuff should be done via a rich js api
TabAtkins: dean is working on css om apis
TabAtkins: go through there
TabAtkins: this allows more powerful things
TabAtkins: that's probably a better direction
vhardy: may need some declarative syntax for that
TabAtkins: hard to do with css model
vhardy: how to deal with multiple animations
TabAtkins: css model is that one animation wins
TabAtkins: we know smil does that
jdaggett: i'm worried about referring to smil
the complexity of smil scares me
vhardy: it's complex but it's doable
<arronei> I'm worried that this is complicating CSS too much.
sylvaing: the lack of an api is painful
<jdaggett> arronei, +1
sylvaing: for developers
<arronei> We used to have a behaviors spec for CSS this might be worth
moving in that direction.
Scribe: fantasai
IVS Policy
----------
<fantasai> http://lists.w3.org/Archives/Member/w3c-css-wg/2011AprJun/0427.html
fantasai: I think we should send a comment to Unicode saying that their
policy of allowing different people to register different
IVS's for the same exact glyph is a problem.
<kojiishi> http://itpro.nikkeibp.co.jp/article/COLUMN/20110124/356398/
jdaggett points to example in that page
jdaggett: This is one single codepoint. The second codepoint listed is
the IVS, which says which variant to use.
jdaggett: If you look carefully, you can see he variations
<dbaron> looking at variants of 邊
jdaggett: There's a whole range of variations
jdaggett: But what you'll start to notice is that if you look at fonts
that support some of these variations, they map several IVSes
to the same glyph
<dbaron> fonts map E0100 and E0108 variants to same glyph, etc.
jdaggett: The way this work is that different vendors can come to Unicode
and register variants
jdaggett: But there's no process that requires them to go through the
existing registration to see which of their variations already
exist
jdaggett: That whole problem is foisted onto users and font developers
jdaggett: the NTT guy said it's a lot of work to figure this out, but
that's just foisting the job onto all the font developers
Nat: It's in his interests to keep up the silos.
jdaggett: They don't realize that the way in which they've done this,
they're creating interop problems for authors and for
implementers like us
jdaggett: So there's that problem
jdaggett: What fantasai has written up is a letter ..
jdaggett: There are proposed changes to the process that would encourage
vendors to share IVSes.
jdaggett: fantasai's proposal is to make that stronger, that registrants
must say what the differences are and write it in text in order
to register a new IVS
jdaggett: The differences can be very subtle. It's hard to tell, without
prose, what differences are being registered, and which
differences aren't being registered or whether this is just a
duplicate
Steve is concerned about being tactful
jdaggett: Interop isn't something that exists only outside of Japan.
Nat: This comes partly because of the silo issue, but also because it
isn't articulated clearly enough what the main thing is you're
trying to solve.
Nat: I think what they saw with IVS was that they could encode all
these incompatibilities in glyph shape into Unicode
Nat: They see it as the opposite of what it's for, it's not your
responsibility anymore, you can register any IVD registration
Nat: what should have happened when the second IVD collection was
registered was to say, "No, that's not what this is for."
Nat: To have more than one collection means that you have a body
that needs to determine the interactions between the collections.
Nat: Why have more than one collection? Why not have only one collection?
Nat: And have new glyphs interoperate with existing set
Nat: If you're not having a flat model, then what are you trying to do?
Nat: If I'm right and the original purpose was to solve interop, then
we really need strong language
Nat: Saying that itnerop is the main problem we're trying to solve,
and explaining all the new problems, will help convince Japanese
that this is the right way to go.
Yamamoto: They tried to .. set of glyph, but they couldn't because the
granularity changed.
Yamamoto: For example, government needs more granularity for people's names
Yamamoto: ...
Yamamoto: So they reached conclusion that it's impossible to have one
universal list of glyphs
Yamamoto: So this was born, and that allows different parties to submit
different IVD collections
Yamamoto: But they're currently planning to amend the process to
encourage sharing and coordination between groups with similar
glyphs
Yamamoto: That is the historical description.
jdaggett: It's that proposal that we're suggesting to comment on
jdaggett: Unless it's written more strongly, they won't bother. They
should cooperate, but it takes too much time.
jdaggett: I think the language proposed is good,
jdaggett: I think we should take Steve's suggestion and also focus on
the problem of interop within Japan
Yamamoto talks about some committee about discussing IVS interop
Yamamoto: At that meeting we will discuss ways to improve the current
situation.
Yamamoto: Such as having a mapping table between different IVD collections
Yamamoto: Or more documentation on granularity.
fantasai: ...
jdaggett: One issue here is is, look at these two differences -- this
glyph has a concave stroke, the other one has a convex stroke
jdaggett: These differences are erased in a gothic style
Nat gives a history of a glyph diverging and merging and diverging
jdaggett: This starts to get involved into font fallback
jdaggett: A lot of gothic faces won't implement these differences
jdaggett: In most web pages, if the font is a gothic style face, if you
require fallback to that selector, you're going to see a run
of text that's going to hit Mincho, and that difference is
going to be far greater than any of the subtleties in these
variations
Nat: The gothic face will just unify the glyphs, have the same glyph
for both codepoints
jdaggett: There will be UAs that try to do the right thing and show
the variant. That will look worse than UA that does the wrong
thing
RESOLVED: Send comment to Unicode on behalf of CSSWG requesting stronger
requirements for sharing IVSes across IVD collections.
font fallback with IVS
----------------------
jdaggett: My standpoint isn't that I want one way or another, but that
there's a tension between doing the right thing and showing
the correct variant, and keeping a consistent style of text.
jdaggett: For a lot of users, the distinction is too subtle, which they
won't notice, but they will pick up the style change.
Yamamoto: There can be 2 different views on this issue.
Yamamoto: If we have theoretical character model
Yamamoto: Yes, there are exceptional cases such as Gothic and display
faces, where such subtle details are gone
Yamamoto: But there are a variety of typefaces in Mincho style, there
are many different designs of Mincho categorized in Mincho style
Yamamoto: In that scope, I think it is possible to notice the differences
in these glyph shapes.
Yamamoto: For example when the govt wants to use differences in glyph
shapes for purposes of their database for people's names or
place names, if they want to use IVSes to distinguish subtle
differences based on Mincho style
Yamamoto: They may think that oh, if one IVS and its glyph can be
represented by different Mincho typeface, they may think this
single IVS is slightly abstract nature as a glyph, abstracted
glyph, and not the lowerlevel typeface-dependent glyph images
Yamamoto: I think understanding of most ppl in govt and financial org
where they need to distinguish such subtle differences, seems
to be limited to scope of Mincho style. So important govt docs
printed in Mincho typeface.
Yamamoto: So I can agree with you, but there is another way of looking
at this.
Nat: One point you may want ot emphasize, is when doing fallback, when
doing catastrophic fail of the system ...
jdaggett: You said that yesterday, and I want to say this again -- on
the Web, fallback is the normal thing.
jdaggett: If you bring up Facebook, you'll see a bunch of languages.
the only reason those are ever displayed is because UAs search
through the system for a font to use to display them
Koji: Even within Japanese, authors tend to want to show glyphs while
designers want to use consistent typefaces. So it splits.
jdaggett: I think that's not true. I think authors would like things
displayed nicely, too.
jdaggett: Kobayashi-san wants it one way, and person working at Magazine
wants it another way
Koji: If author things the difference is subtle, they shouldn't use IVS.
It shouldn't be asked to decide, it should be author's ...
Koji: if author cares, the difference is important to him.
Florian: It says the author cares. Doesn't say whether author cares enough
to switch font.
Nat: I'm concerned about author knowing so much about the encoding. They'd
just pick from a glyph palette.
Nat: When developing content that might involve font fallback, we should
give the author ability to choose whether they care about the exact
glyph shape or the font consistency.
Nat: Because of the tension you menion, I think there should be
infrastructure to support a preference of some kind.
Nat: Author should know that UA might not be able to display things as desired
Nat: All of these combine to make a situation.
Nat: When there's a conflict, we should give them a choice.
Yamamoto: govt or police or CIA may want abstract glyph instead of typeface
consistency. But graphic designer or commercial advertisement,
yeah, abstract glyph shape can be less important.
Nat: I think also if we make that choice explicit, it will help ppl
registering in the IVD to realize whether their variant is purely
stylistic or whether it is more semantic.
Nat: This font fallback scenario helps people understand that.
jdaggett: One problem we have in CSS is, font fallback, we have a couple
different flavors.
jdaggett: A lot of discussion has been simplified or oversimplified.
jdagget writes:
font-family: fontA, fontB;
jdaggett: So if I have a base character and a selector
jdaggett: in an ideal world, you would ask if the sequence is in fontA,
if in fontB, and then go into system fallback
jdaggett: system fallback is a black box.
jdaggett: That's not something that is explicitly specified.
jdaggett: This is currently a one-pass process
jdaggett: We haven't defined how to match clusters as opposed to single
characters, but it's a character-based model, and it's a
one-pass model
jdaggett: You go through font list, and then you hit system fallback
jdaggett: When you consider IVS, need to think maybe there's a 2-pass
process tha needs to happen
jdaggett: So, in many mailings that have been posted, appear to describe
as 2 options:
1. You take the combination of base character and selector,
go through the list looking for a match. If you don't find
one, you use base character and look for a match again
2. Go got to first font and check for char + IVS, then check
for base character, then go to second font and ask for
base+IVS, etc.
jdaggett: Those are just 2 of several options. Because you have this
black box here.
jdaggett: Question is, when do you hit the black box.
jdaggett: In 1, do you hit the black box with the combo before going back
with the base character?
jdaggett: Or do you only hit system fallback if you can't find either
the sequence or the base?
Florian: Not sure this helps with having a choice
jdaggett: ...
jdaggett: This problem (points at IVS example) makes things even worse,
do you look at interrelations between variants?
Koji: I would like to show an example of how I would choose glyphs.
Koji: It's not about IVS, but even before IVS we have some variants
Koji: I'm going to show how I would type user name today.
Koji: I'm typing watanabe, and this is the IME conversion.
Koji: It's picking up from my Outlook contacts
Koji: Different Watanabe's in my outlook contact have different glyph
differences
Koji: I don't remember which glyph, but it's in my contacts
Koji: But it's important to get it correct for people names
Koji: So this is built into IME.
Florian: I think the point is that the person authoring the document
might not realize that they're picking a very particular glyph
jdaggett: So you're saying you don't know whether this is using an IVS
or not
Koji: Right. If this displays different on his computer, I would be
very disappointed.
jdaggett: ...
jdaggett: I think what Nat is suggesting is interesting, for example
in a name list you would choose to show the correct glyph,
but in a more general context you would choose to preserve
the font style
Yamamoto: ... family name distinction is done by subtle distinctions
at abstract level, and that is important. For large group
of ppl in Japan, they require what Ishii-san said.
jdaggett: So the problem is, if the policeman has the Hanyo-Denshi
font, and your system doesn't have it, what happens?
jdaggett: There's a subtle point here wrt how UAs evolve.
jdaggett: We all know that features have a way of going beyond what's in
the spec very often
jdaggett: My concern with this is that there'll be a natural temptation
to do improvements, such as incorporating mappings between
Hanyo-Denshi and Adobe Japan 1 and default glyph
jdaggett: If one UA does that, then all UAs have to do that.
jdaggett: So my idea is to disallow that in the spec.
Nat: Same problem exists today with mobile phones
Nat: When you send from NTT Docomo phone to ??, the SMS gets translated
to something that will work.
jdaggett: I want to put in that cmap tables are used, only.
jdaggett: I don't want all implementations to cart around a mapping table.
Steve: If the problem get solved at the registry level
Steve: Then it's easy fo rpeople to be consistent because there is in
theory only one sequence for each
Steve: The next suggestion is to require font vendors to have mapping tables
Steve: Then the user doesn't need to do it
Steve: It could also be solved at the UA level
jdaggett: For this version, those tables don't exist, and we create an
interop problem if different UAs use different tables
Steve: My final point is that somewhere some group should create that table
Steve: Which will be copied everywhere.
Nat: Fonts are a notoriously unreliable place to put such mapping table.s
Nat: We are constantly updating our stupid Unicode tables in these fonts.
Nat: There are so many inaccuracies in our font tables.
Steve: Moving the solution to a different place doesn't solve the problem
of building the table.
jdaggett: My point is that it would be unfortunate for everyone if we
tried to do the right thing, incorporating some complicated
algorithm, and then that complicated algorithm, by user demand,
gets foisted on other people.
...
Nat: I think clear wording in the spec is good.
Nat: With this issue, but there's a conflict between ppl wanting to use
Adobe Japan 1 and Hanyo-Denshi
Nat: I think there will be resistance for font vendors to use both mappings.
Nat: Hanyo-Denshi variations are built for a certain user set in mind.
Nat: And some of these variations are so subtle, that they are almost
stylistic variations.
Nat: They're provied for govt use or whatever
Nat: Adobe-Japan 1 is not a government use table
Nat: I think it'll be difficult for each font vendor to map to the govt
glyph shape database
Nat: Which is what it's becoming, instead of semantic-meaning database.
Nat: So we need this table, maybe it goes in the black box, but then
everyone has different black box
jdaggett: I wanted to point out one thing Kawabata san put up on the board.
jdaggett: One thing he put up was [base char][IVSx][IVSy]
jdaggett: so that was fallback in the character stream
jdaggett: This.. if you look at how this was defined, there's a single
selector. You can't have multiple selectors.
jdaggett: We should explicitly put in text saying the second selector
is malformed.
Nat: It's interesting thing he's decided is necessary. Points out that
fallback.. because of the way IVD colections came about, fallback
will have to be customizable
Nat: Could be more fuel for your letter. Here is someone who wants to
customize fallback. Obviously there's a problem here.
Koji: I think there were two issues mixed.
Koji: One is whether to fall back IVS first or font first
Koji: Other is mapping between different IVD collections.
Koji: For the latter, I don't think it's necessary. It's not application's
responsibility
jdaggett: I'm saying it's not just unnecessary, but we have to say it's
not allowed. Otherwise some applications will include it in
their black box.
jdaggett: This table doesn't even exist, so ...
Florian: Can we address separately the two issues?
Koji: What I care is first one.
jdaggett: I hadn't considered Nat's proposal to allow a choice
Florian: We have a switch in CSS, and give an algorithm for each option.
Florian: I think it's only possible to pick the best algorithm for each
priority
Florian: Not hard to decide on the algorithm once you have priority
jdaggett: So my proposal would be to look for the correct sequence first,
all the way to system fallback. Then go back and do base character.
jdaggett: And have a switch for preferring font consistency.
jdaggett: Keep in mind that the text includes the IVS, so if you cut and
paste it you preserve this info
Nat: Imagine a publishing-proofing system.
Nat: In desktop systems, we want to make it really obvious when a glyph
is missing.
Nat: This way the proofer could immediately see that this character was
missing or wrong
Steve: You could use a font that maps every Unicode codepoint to the geta
character (missing glyph thing)
jdaggett: So, first point is, that's not a general feature. It's a
user-agent level feature.
Nat: ...
jdaggett: Oh, you're talking about a Web-based authoring environment
Steve: Just hijack it by using the fail-character font
Nat: Ok, that works.
Nat: U+3013
jdaggett: Ok, so that's all I have to say. I'll work on adding the wording here.
jdaggett: Unfortunate that this complicates font fallback, but that's par
for the course.
RESOLUTION: font fallback goes all the way to system fallback with the
IVS before repeating with base, will add a property to
switch between that and font-consistency-priority matching
Nat brings up compatibility chars
Koji: I think that's a separate topic, and not CSSWG responsibility
Nat: No, but add to Unicode feedback from CSSWG.
ACTION: fantasai mention compat characters in mapping table request
<trackbot> Created ACTION-322
Scribe: Tab Atkins
CSS3 Text
---------
murakami: I think 'white-space-collapse' is a good name for the property.
murakami: It's not a big problem for XSL-FO to have a property of the same
name but different values, I think.
murakami: They're sufficiently different.
<fantasai> Note: Murakami-san is an implementer for Antenna House Formatter,
which supports both CSS and XSLFO
szilles: So what happens if I embed SVG in both?
szilles: It makes sense for SVG to do whitespace collapsing.
szilles: The agreement we had was that if we were going to change the
property value, we should change the name.
murakami: With 'white-space-collapsing', is the "ing" a big problem?
fantasai: Just clumsy, especially with 'border-collapse' already existing.
jdaggett: Why not just call it 'white-space-collapse' for now, mark an
issue, and look at it later?
fantasai: That just puts us in the same boat.
jdaggett: Just to have it not be "bikeshedding".
<TabAtkins> "whollapse-c-space"
dbaron: 'collapse-white-space'?
szilles: 'text-space-collapse'
RESOLVED: Change to 'text-space-collapse'.
fantasai: Let's look at the ToC and go through issues.
Nat: My main priority is things to do with japanese punctuation adjustment.
jdaggett: [explains the standard model of pruning specs after experimental
impls start]
fantasai: Let's start with linebreaking, then spacing, then text-justify.
CSS3 Text: line-break
---------------------
fantasai: ie6 implements line-break:normal and strict, and then we added
another level, and an 'auto' value so the UA can pick whatever's
appropriate (mobile phones want looser, probably)
fantasai: The definition is fairly vague - lots of UA freedom.
fantasai: In strict breaks are forbidden before small kana and some other marks.
fantasai: [more description of the property in the spec]
jdaggett: Is there stuff in the jltf recs that give you character classes
for this info?
fantasai: We do point to the jlreq document for recomendations, but...
jdaggett: I'm looking for something more detailed.
jdaggett: I'm fine with codepoints being listed as a character class in a
normative appendix, so then we can just refer to character
classes in the normal spec descriptions.
fantasai: Ok.
Nat: I don't think the jlreq character classes are used for linebreaking.
szilles: They sometimes are, and sometimes aren't.
kojiishi: Toppan said that they wanted to specify individual characters
for "kinsoku rules" (characters you can't break on).
florian: General interoperability concern - while this helps for cj, it
potentially makes the interop bad for other types of languages.
florian: Because there aren't any details other than the cj stuff.
fantasai: Unfortunately, the rules for linebreaking are very specific
to the language...
fantasai: We're not trying to solve this, and exactly specify it, but in
Japanese they care about having different levels of linebreaking.
fantasai: We could specify that in languages other than cj, the property
has no effect, or has no effect *right now*.
jdaggett: Is this tied to the language tag?
fantasai: Somewhat - there are several breaks that are based on the language.
jdaggett: I ask becuase you can have mixed-language documents.
jdaggett: So you shouldn't be using the japanese rules. And there are
English-breaking rules, where in japanese you'd instead do some
relatively odd things (like breaking in the middle of an english
word).
fantasai: That's handled by the next property.
florian: [something I missed]
fantasai: Impls have a compromise breaking algorithm that tends to work
decently on most languages as a default
florian: So if you say 'strict', does it only work on japanese?
fantasai: They work in all languages, but the rules specifically refer to
japanese characters, so it won't effect other scripts.
florian: If we extend this to other languages, we may not be able to use
pure codepoints. We may have to say "if in french, do this".
fantasai: We already have that here - we have some rules that are specific
to chinese-only or japanese-only.
fantasai: The language-specific rules are orthogonal to the level you're
working on.
florian: But if we later let 'strict' work for English...
fantasai: -- like, "only break at spaces"...
florian: ...we'll have rules in Japanese that say "break at hyphens" and
in English that say "don't break at hyphens".
fantasai: We've got a division between the generic rules, which every
language would do, and then the lang-specific rules
fantasai: *Only* if you're language-tagged do you get the language-specific
rules.
florian: So should we say that in "generic mode" there's no difference
between levels?
fantasai: There is a difference, but they're code-point specific, so they
won't affect other scripts.
szilles: I suggest we split it into "generic" which is just the 'normal'
value, "code-point specific" which has the code-points for each
level, and "lang-specific" has even more specific rules.
[discussion about how specific it is to refer to code-points]
fantasai: The point is that the linebreaking algorithm is defined across
*all* of unicode. Most languages that use a given codepoint
use the same linebreaking for those codepoints. But there are
exceptions where line breaking is language-specific.
szilles: The point is that, in the generic set of rules, there is *no*
strict category. It is defined to be, by necessity, identical
to 'normal'.
szilles: So we should be absolutely clear that, in the generic case,
there's only the one algorithm.
Nat: Each publishing house has their own rules for what's appropriate.
There's some consensus, producing some lists for what's appropriate.
Nat: But here in this spec it's *so* vague. 'normal' is defined as
"use the most common set of linebreaking rules", but what is "most common"?
fantasai: So how should I define this without listing codepoints immediately?
Nat: I suggest using very generic names - "level1", "level2", etc.
fantasai: We can't change the value names - 'normal' and 'strict' have
been implemented for a long time. We only added 'loose' and 'auto'.
Nat: Ok. So, given all the variability in what's going on here, why
specify it at all?
Nat: Anything other than 'strict' is basically meaningless, because it's
far too varying.
[some discussion I couldn't pick the point out of in time, so was lost]
Nat: I think it's unfortunate that the spec, then, doesn't really improve
on the situation as it currently exists.
florian: I think the property is intended to help cjk without hurting
anyone else, but according to Nat it's not helping all that much,
because it's not clear enough.
<florian> adding to my previous comment: and for the non cjk world, it
risks ecouraging a proliferation of different algorythm where
we didn't want one, and cause interoperability issues.
fantasai: I can go copy someone's house rules and put them in the spec,
if that's what's wanted.
szilles: I think the point is that any solution that tries to do a halfway
approach to the problem is going to fail. It'll end up as a
20/80 solution, instead of 80/20.
szilles: What I'm hearing is that not having any variation at this level,
and coming up with language-specific ways of putting stuff in
(kinsoku tables, etc), is basically necessary here.
fantasai: I believe that the specifics of the house rules aren't important.
Authors won't care. Publishing houses do.
fantasai: People using Word basically never alter the kinsoku tables.
jdaggett: One problem is that you're talking about an application, where
the same rules are used across all computers, but here we'll
have browsers with multiple rules.
szilles: I think that, if you're adopting MS's properties, you should
just accept Microsoft's rules. I'm not saying they're the best,
but hey, consistency.
fantasai: So, I went through the jlreq lists and pulled out the behavior
that you must do generically, what you must do for certain
languages, etc.
fantasai: I can't be absolutely exhaustive because it keeps changing/growing
kojiishi: Word has 3 levels for Japanese - normal/strict/custom - but only
one for Korean - normal. InDesign is similar. We want to avoid
the language-specific stuff as much as possible.
szilles: I'm curious about who you're trying to satisfy. The publishing
houses aren't happy, and if the normal authors don't care, can't
they just do 'normal'?
kojiishi: Normal users *do* switch between normal and strict, though.
florian: You're not saying that if you haven't labelled with a specific
language, not to change anything.
fantasai: So you're saying that it should only work if you have a language tag?
florian: If someone has a single awesome linebreaking algo, that's okay.
But do we want to invent four?
fantasai: Yeah?
Bert: Go ahead! Invent as many awesome algorithms as you want. This is good!
Bert: I think we only need two values - "auto" and "strict". I usually want
the best linebreaking algo the UA can figure out, but occasionally
I'll want to specifically say "strict".
Nat: I want an explicit control for "normal", because I may not want the
UA to switch into strict/loose based on some arbitrary criteria.
fantasai: let's say you're on desktop, but you want a newspaper-style
presentation (multicol with narrow columns), you'll want very
loose breaking, looser than normal content. That's why we have
"loose".
szilles: What I have trouble with is that any of the "loose"s are arbitrary.
fantasai: They're all arbitrary.
fantasai: We figured three was a workable number for most people.
Nat: Ok, but we then need a way to explicitly specify some sets via an
extension mechanism. People that don't care will just use "auto".
Nat: In InDesign there are four lists of rules - "can't begin", "can't end",
etc.
szilles: For this round, we don't need the extension mechanism, we just
need it to be possible to extend into that.
szilles: Since we're stuck with two values (normal/strict), I just don't
see why we need the third value (loose).
Nat: I'm just sad about the name - "normal" basically means
"sometimes loose". ;_;
fantasai: So I'm going to pull out the codepoints into an appendix and
make it clear that non-CJK codepoints aren't affected, and will
mark 'loose' as at-risk.
Bert: I'd prefer not to extend this in the future. I'd like to just
finish it now with the features we need.
szilles: There are people who need this now, without needing the specific
kinsoku rules. It would be a disservice to hold it back while
we wait for that.
sylvaing: I don't have exact numbers, but I know that usage of Word's
normal/strict controls are relatively little-used.
Nat: I think the property is fine because it matches the UI exposed by
authoring tools. I don't think it's as useful as those authoring
tools, though, because it's more open-ended.
<nmccully> About Kinsoku: We should admit that the spec as-is can only
really give UA the ability to choose between arbitrary behaviors,
without explicitly being able to define what those are.
<nmccully> So, perhaps we should eliminate all language the describes
the behaviors
<nmccully> Just say you can pick between "normal" and "strict" and
those behaviors are not defined currently
<nmccully> in the future we will allow customization, which gets you
what you want
<nmccully> I think there is value in being able to differentiate between
the two behaviors, so the above is preferable to me than
dropping the feature entirely.
ACTION fantasai: Pull out codepoint lists into an appendix and make it
clear that 'line-break' doesn't affect non-CJK codepoints
in language-generic mode
RESOLVED: Mark 'loose' at-risk
<br type=lunch duration=1h/>
CSS3 Text: text-spacing
-----------------------
fantasai: We've recast this feature multiple times.
fantasai: One thing that happens when typesetting japanese is that when
you have certain punc character together, their spacing is
adjusted.
fantasai: another is that some people like to insert spaces between,
frex, latin and ideographic chracters.
florian: Why does this have to be automatic?
fantasai: You switch scripts a lot in jp, without switching languages.
Jp is basically made up of 4 scripts at this point.
fantasai: trim-start/end removes spacing at first/last char on line to
make it align closer to the line.
fantasai: 'normal' is normal behavior. 'none' sets everything in 1em
squares.
fantasai: And we have trim-start or space-start, which determines whether
to do full-width or half-width on the starting edge of a line.
fantasai: trim-end/space-end do the same for the end of a line.
fantasai: And allow-end *allows* you to trim if the last char doens't
fit, or make it fullwidth otherwise.
fantasai: 'trim-adjacent/space-adjacent are similar, but within a line.
fantasai: Then you have the values for spacing between alpha and
ideographic characters.
fantasai: That's almost a different feature. You're adding space rather
than taking away space.
fantasai: But that depends on your mental model.
florian: I ask if it's actually separate features because Håkon objects
to the second feature, not the first one.
florian: The french actually put spaces in their text when this sort
of thing is desired.
kojiishi: It's a stylistic variation only.
fantasai: These used to be two features. text-trim was the first several
features, text-auto-space was the alpha/ideographic ones.
Nat: I think it's okay to combine them.
Nat: I think the property may not offer quite as much control as necessary
to achieve pretty display, but otherwise it seems okay.
Nat: Is there a concept of line compression? How do you adjust the half-em
space here? Like if the line is too long and I need to compress the
space, how do I do that?
fantasai: By default, you can justify by adjusting those spaces, and we
have an option to turn that off.
Nat: Does that usually mean to expand the space, or can it compress the space?
fantasai: Up to the UA.
Nat: It seems that you're only talking about push-out style justification
in the spec.
kojiishi: The text-justify property allows you to do anything.
CSS3 Text: text-justify
-----------------------
fantasai: [explains the text-justification property]
Nat: If I want to, in a line of text with a japanese period, compress that
space last, a good UA will do that by default, but a phone may not
in a tight line. I'd want to change that behavior.
Nat: So it would be good to have some markup allowing me to specify whether
that happens or not.
florian: What are the priorities for things?
fantasai: glyphs-shaping, for example, is listed as out-of-scope.
UAs can do it if they want, but we don't have a control for it.
fantasai: Frex, in Arabic you can do really beautiful justification by
swapping out alternate forms. But that's really sophisticated
and font-specific, and I can't define that.
fantasai: There are no controls or restrictions for priority within punctuation.
kojiishi: We've brainstormed abilities for the future that would allow
better priority-control, similar to what InDesign does now.
fantasai: (to Nat) Are there particular controls you would find important
to add?
Nat: I don't think it's necssarily important to provide what InDesign has.
Nat: But could you make it any simpler while achieving similar results?
fantasai: What would you simplify?
Nat: Right now what you're saying is that the line-ends are important for
fullwidth punctuation.
Nat: That is, lineend->punctuation is one pair, alpha->ideograph is one
pair, etc. Do you have ideograph->ideograph?
fantasai: No. That spacing can be justified, but you wouldn't do
exceptional spacing by default.
Nat: What about jp-en-jp in a line, and justify it? Some justifiers
will put all the spare space in the ideo->alpha spacing. Others
may space the jp and keep the alpha tight. Others may space
everything.
fantasai: We also have a letter-spacing and word-spacing property which
lets you set the spacing defaults, and put limits on them.
fantasai: So you can control that sort of thing more precisely with those
properties.
fantasai: I think currently the spec would say that the space the cjk up
to the limit, and then drop down to expanding the roman.
fantasai: It sounds like you want to expand the cjk to max, and then
expand both roman and cjk.
Nat: Yeah, sometimes in these exceptional circumstances you just need
to violate all the max constraints.
fantasai: That makes sense, and I'll change the spec to say so.
szilles: I think the spec should give these things as examples, and
show how to use them together to get what you want.
Content: CJK-Roman-CJK
* expand only spaces
* expand cjk and spaces
* expand cjk first, then everything
^^^ needed examples
Nat: Also, JIS has 18 classes of punctuation. Here we simplify it down
to one style of punctuation, which seems too simple.
fantasai: In terms of punctuation, it's like glyphs substitution - it's
out of scope for our controls, and UAs should do whatever is
intelligent.
fantasai: I could *theoretically* get enough info from the japanese to
get a spec for justification, but I couldn't get the necessary
detail in any reasonable amount of time for any other language.
fantasai: You could write several lifetimes of PhD theses on justification
around the world.
Nat: Ideally there should be a prioritization for how the existing spacing
pairs (ideo->alpha, ideo->linestart, etc) get applied.
Nat: In the justification table, it looks like spaces are always expanded
first, and then everything else at the same time.
fantasai: Normally you *do* always expand spaces as much as possible,
and only do other justification if there's no spaces.
Nat: God help anyone with spaces on their line.
fantasai: And for cjk you may want to set a conservative limit on the
space-size (with 'word-spacing'), so it'll exhaust the spacing
expansion and switch to other things.
Nat: So you require a cjk author to set a relatively small space max-length,
which may justify roman text badly.
fantasai: The default behavior for word-spacing takes "normal" for both
min and max spacing, which can vary based on many factors including
the language. Basically, UA-dependent.
jdaggett: What's the column for 'auto' for text-justify?
fantasai: It's the default, and lets the UA choose whatever is reasonable.
What's suggested in the table is a simple universal compromise.
[discussion about the presentation of the table for easier reading]
fantasai: Okay, I'll change the 'auto' character to an asterisk with an
explanation, and switch each column from 2-col to numbers.
fantasai: And add glyph-scaling to the methods as "whenever".
florian: Another comment from Håkon - this is meant for documents where
authors care about pretty formatting.
florian: But this reduces the ability of UAs to prettily justify by default.
You can't do TeX justification.
fantasai: No, you still can use TeX to determine the optimal compression
and such. This just tells you what's most important to expand,
per the author's own preferences.
florian: What's the best default value for English?
fantasai: inter-word
florian: But TeX won't expand spaces fully before switching to other spaces -
it prefers to expand spaces, but will start expanding other things
as well eventually, even when spaces can still be expanded.
florian: That doesn't work here, if you have to set hard limits to make
spaces stop expanding.
szilles: Perhaps instead, the controls can be phrased as essentially hints,
such that UAs *can* do more intelligent algorithms, as long as
they take the preferences into account.
fantasai: Yes, though the min-space is still a hard limit.
ACTION fantasai: Make text-justify tables use numbers, footnote auto column
ACTION fantasai: Add examples of text justify from minutes
ACTION fantasai: Make text-justify tables use numbers/'never'
ACTION fantasai: Make it clear that glyph substitution is neither
required nor forbidden
ACTION fantasai: Fix spec so that lower priority includes earlier
priorities
ACTION fantasai: Make punctuation justification priorities more
clearly out-of-scope
ACTION fantasai: Make it clear that TeX-style cost-based distribution
is allowed and add an example with 'inter-word'
CSS3 Text: text-transform
-------------------------
jdaggett: Now that fullwidth is in the property, what's its priority
relative to uppercase/lowercase?
fantasai: I think we talked about that, though I don't recall exactly.
jdaggett: The case mapping rules here in the spec are woefully underdefined.
fantasai: I think the bar is the full unicode casing algorithm.
fantasai: But we want it to be able to be smarter than that.
jdaggett: I want something testable.
fantasai: Yeah.
jdaggett: Also, what's the relative ordering of all of these properties?
Some properties are based on character class, and text-transform
is changing the character class.
fantasai: Ok. I'll make a normative appendix specifying the order they're
applied.
jdaggett: the order of value is fine with me:
[ capitalize | uppercase | lowercase ] > fullwidth > fullsize-kana
florian: Håkon wants to know what the <wide> tag is, that is mentioned
there in the spec.
[discussion about the <wide> reference]
jdaggett: I want a clearer explanation of how to understand the unicode
database file and map field X to field Y.
dbaron: Like "the sixth field of the database (decomposition_mapping)", etc.
<boblet> (Unicode data file using <wide> etc being referenced was
http://unicode.org/Public/UNIDATA/UnicodeData.txt btw)
wrt fullsize-kana
Nat: You don't use small kana in ruby, for readability. You always use
large kana.
Nat: When you author, you input large kana, not input small and then transform.
Nat: For accessibility, I'd hope you don't look at the ruby data for
screenreading.
szilles: People learn to interpret the large kana and small kana by context,
but a screenreader needs additional info - one suggested additional
info was to input small kana, but it's not good enough.
kojiishi: Some ruby uses small kana for stylistic purposes.
florian: But then they don't transform, they just scale it up to be readable.
<dbaron> example of しゃ vs. しや
<dbaron> (though Elika wrote them in the other order: しや (shi ya) vs. しゃ (sha))
fantasai: So, displaying ruby as large kana is a stylistic choice.
You want the correct characters in the content, as the ruby
may be displayed inline with parens, but you may want to
transform it to large kana for readability (or scaled small
kana) if the ruby is above/below the main text.
murakami: And some publishers specifically want small ruby with small kana.
Also, educational materials for proper teaching of pronunciation.
florian: In this context, do we care about the codepoint switch, or is
the glyph-switch sufficient?
fantasai: I think glyph switch is sufficient.
florian: Except for the 'fullwidth' value, because other properties change
behavior there.
fantasai: Well, you'd need to do a glyph switch *and* switch the behavior
of those properties too. But you don't strictly need to swap
the codepoint for any value of text-transform.
florian: There's a note that says "maybe use font-variant:ruby"
is that something else?
jdaggett: It's just another glyph that uses fatter strokes, specifically
for ruby.
jdaggett: [airs some concerns about the applicability of the fullsize-kana
value, since it's pretty much only used for ruby]
florian: Håkon suggested "text-transform-replace", basically identical to
Perl's tr///
fantasai: That would solve the case, yes, but it also adds a *lot* of
complexity for solving this one case.
florian: Håkon provides other use-cases for georgian, or to remove accents.
fantasai: Removing accents is not that simple. You also need to normalize.
fantasai: And nobody's actually asked for georgian transforms.
szilles: What did we do for the list rule?
fantasai: We defined a few in css2, then realized we had a *bunch* more
that we wanted to define, so Tab made an at-rule and provided
a UA stylesheet to provide a bunch of defaults.
szilles: Why won't that work?
fantasai: It would. We could do that. But I don't think it's worth it
at this point.
danield: Can we call it 'fullsize' instead of 'fullsize-kana'?
fantasai: It *only* affects kana. There are other types of characters
that come in reduced and fullsize versions that we don't want
to imply would change here.
fantasai: It was also brought up that greek and cyrillic have fullwidth
variants, so people sometimes use those for stylistic purposes.
But there aren't any codepoints for those.
fantasai: So we were wondering if it might make sense to let 'fullwidth'
affect that. There aren't codepoints to switch to, but it
would affect the other behavior.
Nat: This seems to be the sort of thing that *should* be happening in
OpenType, properly.
<Bert> [Discussion about "fake" fullwidth greek and cyriliic, because
there is no actual fullwidth greek and cyrillic in Unicode.]
Nat: That lets UAs do all this stylistic stuff without touching the
underlying model.
szilles: But you can't do linebreaking as an opentype feature.
Nat: You can - you can't do linebreaking until you get glyphs.
fantasai: How do you know whether you're linebreaking these characters
as fullwidth or halfwidth?
[possibly there was some confusion here, and fonts don't carry this information]
jdaggett: I don't fully understand the problem you try to solve.
jdaggett: I think putting behavior in text-transform that affects
linebreaking, etc. is a really bad idea.
jdaggett: This is supposed to be simple.
Nat: Any of the transforms can have affects in some language and not
in another.
jdaggett: I understand, but from a user perspective, these subtle
effects seem hard to understand and conceptualize.
Nat: I think it would actually be hard for impls to do the fake
characters without codepoints.
jdaggett: [something about font features existing for uppercasing, etc.
that I didn't get]
fantasai: Why wouldn't you turn on uppercasing in the font when you
have text-transform: uppercase?
Nat: I think we should resolve not to do any font feature stuff in
text-transform, and complain to Unicode that they should have
made fullwidth variants for everything
Bert: Wouldn't it make more sense to remove all fullwidth variants?
It's a style issue isn't it?
fantasai: I agree with Bert; it seems more like a style issue rather
than something that should be separate codepoints.
Nat: Get rid of the feature (text-transform) altogether and just use
the font mechanism
[ This discussion is mostly unminuted because Tab gave up and didn't say so
and didn't get a replacement]
Scribe: dbaron
Florian: request for tr feature for removal of accents
fantasai: can't be done programmatically - requires a dictionary to
do it right because there are some accents that have to
be kept and some that don't
(discussion about whether it's right or wrong to drop accents when
uppercasing in French)
Nat: sounds like the discussion about ruby
fantasai: Whether you can do this with 'tr' depends on whether you're
NFC or NFD.
fantasai: Correct way to do it is probably do NFD and then remove the
diacritics.
Steve: I'll observe that this is a case where you can't build in the
transform (for the reasons fantasai cited), so having something
like tr which doesn't work well in this case (unless you also
have a normalize function) would allow the user to say what he
wants for his text.
Steve: So this is actually a case that drives the tr solution because
it is different for possibly each document.
Florian: Doesn't solve it universally, but tr is to solve it not universally.
Peter: I think going down that path is out of scope for this discussion.
Peter: Don't want to rathole into proposal for new features.
DanielD: What about calling fullsize-kana fullsize-ruby?
fantasai: No, it fullsizes the kana whether or not you're in ruby,
though it is designed for ruby.
ACTION fantasai/koji: Set minimum bar for case shifting by pointing
more directly to specific Unicode algorithm
ACTION fantasai/koji: Add normative appendix for order of text operations
ACTION fantasai/koji: Define fields used in fullwidth transformation
ACTION fantasai/koji: Make small kana mapping table (reuse for line-break)
ACTION fantasai/koji: Remove note about font-variant-ruby (goes in ruby spec)
ACTION fantasai/koji: Add note about @text-transform possibility
Hyphenation
-----------
Sylvain: Some feedback from a colleague: why are a bunch of the properties
optional? that's tricky from an interop standpoint
Sylvain: "These controls are optional because for a low-end implementation
of hyphenation, they are not critical enough; and for a high-end
implementation of paragraph breaking (such as in Teχ) they are
not considered especially useful. "
Sylvain: Require them? Not require them?
dbaron: removing them?
fantasai: Håkon wanted me to make things optional if they weren't
required for all scripts.
ACTION fantasai: Switch optional properties to at-risk
Sylvain: What is the use case for hyphens: all other than debugging?
Sylvain: I'd like to remove it.
fantasai: Anybody object?
Steve: The UA writer could have settings for that if desired.
Sylvain: Yep, doesn't need to go in style sheet.
Bert: I use show-hyphens in TeX a lot.
John: Do we implement all?
dbaron: No, just none manual auto.
RESOLVED: Drop 'hyphens: all'
Sylvain: word-wrap: hyphenate? Interact with hyphens:none? How does
that work?
fantasai: Only kicks in if there's no other break point on the line
fantasai: Alan suggested dropping that and using hyphenate-zone:100%
fantasai: word-wrap:hyphenate beats the hyphenation controls (hyphens:none)
Peter: ... but only to prevent overflow
Sylvain: What kind of hyphenation happens?
Steve: It's forcing a line break, not really hyphenation
fantasai: It's a forced line break at an appropriate hyphenation point
Alex: ... choice of break anywhere or refer to dictionary ...
(description of what's in the spec)
Steve: It's not just if it's turned off... there are other things that
inhibit hyphenation.
ACTION: fantasai "even if hyphenation is turned off or otherwise restricted"
<trackbot> Created ACTION-323
Steve: If you say word-break, and hyphenation is on, are you allowed
to hyphenate?
(discussion of what characters to use for "TeX")
word-wrap
---------
Bert: Why is word-wrap not called emergency?
fantasai: widely implemented unprefixed
Everyone implements word-wrap: normal | break-word
Peter: Bert has a point; you could add the standard name and keep
implementing the nonstandard one
Sylvain: There's content depending on it.
Bert: Forget about the other one; it's not ours and we don't have to
document it.
Bert: It's confusing to have word-wrap and text-wrap etc. and they
don't do the same thing.
Alex: One point of standards is interop; if multiple vendors have
agreed to do something they can get together and agree on what
it is, regardless of the reasons.
Alex: With a different name, we'll still have to define what the ugly
old thing does just as we define how to parse invalid html.
Florian: If your goal is interop, we do need to define how the thing
everybody supports is actually supposed to work.
Steve: Also defining things that can get through CR in a reasonable
amount of time.
Alex: We can say something is deprecated and define what it does.
Peter: I think there's a valid request to rename the property; do we
want to do that?
Sylvain: The property or the value?
Peter: the property
fantasai: options are 'emergency-wrap' and 'word-wrap'
fantasai: word-wrap is implemented by 4 browsers
Steve: word-wrap seems fine
Bert: It's only a second level option
Peter: More of an overflow management property
Steve: 'overflow-wrap'
John: I don't like "emergency" at all.
Florian: If we're going to rename it, word overflow should be in there.
fantasai: Options: (1) keep as word-wrap (2) rename to overflow-wrap
and document word-wrap as a deprecated alias
dbaron: Need to define what alias means.
dbaron: We have an aliasing mechanism for prefixed properties
dbaron: but it's a parse-time thing
dbaron: If we define an alias, we should make it clear that it's a
parse-time thing
Alex: In object model there will be word-wrap and overflow-wrap?
dbaron: For us, word-wrap would not be exposed in the OM.
[Nat and Taro leave]
dbaron: It would break scripts
dbaron: I'm ok with that if it's not a long-term thing
dbaron: and we don't have situation where things only break in Gecko
Florian: Seems like switching names might be more trouble than it's worth
Bert: more trouble for implementers, but we're thinking about authors
dbaron: Actually, it does work for getPropertyValue() in Gecko, and we
could make it work for CSS2Properties
Peter: For people who don't understand English, using more consistent
terms is probably a good thing.
Peter: Are we ok with option (2)?
Sylvain: Where do we define what alias means?
Sylvain: Difference between saying there's a deprecated property there
saying that if you support that deprecated property it must be
an alias.
Alex: [something about searching for things in Google and trying to find
documentation, which currently is written for word-wrap]
Bert: I'm more concerned about people seeing the property name and
finding that it doesn't do what they expect.
Peter: I've run into that.
Alex: overflow-hyphenate or hyphenate-overflow?
Florian: Put a note saying we're thinking about it? I'm not sure without
talking to Opera implementors.
fantasai: I think we need feedback from WebKit and Opera implementors.
ACTION fantasai: Mark 'word-wrap' -> 'overflow-wrap' as an issue
Peter: break until 4pm
CSS3 Text: Other Features
-------------------------
http://lists.w3.org/Archives/Public/www-style/2011May/0721.html
Florian: Håkon was wondering if we can move 11.2 (emphasis marks) to
the same spec as ruby
Florian: same interaction with line spacing
(time limit on text discussion set to 4:30pm)
fantasai: They are similar in terms of implementation effects but very
different in terms of what they're used for; for authors
they're an alternative to underlining.
Florian: The way it interacts with ruby needs to be described
Steve: Would Håkon like it better if we moved ruby to the text spec?
fantasai: Two problems: From an authoring perspective it's much more
closely related to underlining, and the ruby spec needs a
*lot* of work.
fantasai: Ruby is missing the box model for ruby; the only thing that
needs to be defined for text-emphasis is the interaction with
line spacing; no need to worry about anonymous boxes, etc.,
which ruby is missing.
fantasai: Six months for the ruby spec would be optimistic; not many
issues with text-emphasis.
fantasai: Only concern is line spacing.
Steve: i.e., the decision we made yesterday that it doesn't affect
line spacing
fantasai: I think it should stay in the spec.
Florian: I think it was just a suggestion, not a strong request; I'm
ok with that answer.
Florian: Håkon suggests dropping text-outline; text-shadow is rich enough
dbaron: Doesn't the addition of spread to text-shadow provide the same?
fantasai: you can get the same effect
Tab: What is done by text-outline that's not done by spread text-shadow?
fantasai: nothing I know of; we didn't have spread when text-outline
was added
RESOLVED: drop text-outline
Florian: Either Håkon or I is confused about the hanging punctuation...
Florian: Håkon interpreted is a per-block.
fantasai: It's each edge of each line
fantasai: force-end doesn't actually stretch the content. It doesn't
force the content; it's just that if you justify the line
you don't measure it.
Florian: Can we clarify the wording?
Florian: Was the image example of force-end added?
Florian: only if there is justification... or does it force justification?
fantasai reads from spec
Florian: Can we add the piece of CSS that caused the example to look the
way it is... so the CSS has the justification
ACTION fantasai: Add CSS to the example
<trackbot> Created ACTION-324
Florian: Håkon: Instead of text-align-last I propose p::last-line
fantasai: Doesn't work, since ::last-line applies only to last line
of block, but text-align-last needs to apply for anonymous
blocks, forced breaks, and other lines that can't be
justified for other reasons
Florian: Håkon proposes 'balance' as a new value for 'text-wrap' to
prevent the last line from being too short.
fantasai: I think it's a good idea; somebody previously suggested
'last-line-length: <percent> | <length>', which I think
is a better way of handling that because it gives more flexibility.
Florian: This somewhat mirrors column-fill: balance
fantasai: But I want to push that to the next level of text.
Steve: I'd have interpreted balance (if comparable to columns) as
something that makes all lines equal.
Florian: Håkon was thinking all or the last few
Steve: All is an expensive operation.
fantasai: I think we could consider if we have willing implementors
Steve: could list an issue that 'balance' has been proposed
fantasai: Not sure I'd stick it in 'text-wrap'.
Steve: Probably in justify
Steve: Really applying to the paragraph as a whole.
fantasai: You can have a centered paragraph with balanced lines.
Bert: I think implementations should do this automatically -
try not to make the last line too short or to long.
fantasai: You usually don't want the whole paragraph to have equal lines
Bert: You don't want the last line too short *or* too long
Peter: Lots of other factors
fantasai: We can put this in the wiki for things for future levels.
Steve: There's a min length on last line proposal?
Florian: Håkon proposes text-ident: each-line
fantasai: That's in the spec already.
Florian: How about renaming it to after-break
fantasai: it's not just after-break; it's also at the start of the paragraph
fantasai: It's intended, e.g., for source code or poetry.
Florian: Håkon - I'm unsure if 'hanging' is needed given that negative values
fantasai: negative values put you in the padding; shouldn't have to
match the padding to text indent
Florian: Last item from Håkon on 5.2 (word-break): this section
should benefit from examples. (quoting)
fantasai: Agreed
Florian: ... suggest defining shaping scripts in Appendix E. ... (reading)
(traffikkonstabel)
fantasai: Those things should be handled by the hyphenation engine,
which should make appropriate spelling changes
fantasai: That note is saying that, after the hyphenation engine,
that Arabic is still *shaped* as though word was not broken.
Steve: Should probably say explicitly that you use initial/medial rather
than standalone/final before a break, and medial/final rather
than standalone/initial after a break.
fantasai: Actually, I think we shouldn't specify the rule because it'll
be wrong; better to give example.
Florian: That's the end of Håkon's issues.
fantasai: I propose dropping hyphenate-resource
Steve: Not now
fantasai: I'll do it when we request last call.
Scribe: fantasai
Discussion of what to discuss
Charter
-------
<jdaggett> who needs a charter...?
<Bert> -> http://www.w3.org/2010/09/CSSWG/charter.html draft charter
Bert: 3 questions
Bert: W3C Team looked at charter, esp list of modules
Bert: Maybe Chris forgot to fix things,
Bert: But wondering why Ruby Annotation REC is in the charter
Everybody agrees that should be removed.
Bert: Thinking to move JLREQ to Joint Work
Agreed
Bert: It says CSS1 in Maintenance, but not CSS2.
Bert: CSS2 is not deprecated yet
fantasai: So let's deprecate it
<jdaggett> yes please
Bert: But is everything there in a CSS3 spec?
fantasai: well, the features there not in 2.1 are all in WDs
fantasai: @font-face in the fonts spec, text-shadow in the CSS3 Text
spec, list-styles in css3-lists
fantasai: And some things we're not interested pursuing, like
display: compact
fantasai: display run-in needs to be put in css3-box spec...
dbaron: fullscreen is styling things that are in fullscreen presentation
and some associated DOM APIs
dbaron: It says CSS UI is new when in fact it's in CR
Tab: we have UI3 and UI4
dbaron: oh, ok
RESOLUTION: List CSS 2.0 as maintenance, asterisk saying to be obsoleted asap
jdaggett: are we leaving priorites as is?
dbaron: I'm a little worried about things being on the discontinued list
dbaron: I'm working on a draft that's an extension of syntax
dbaron: I'm not sure what to call this draft, right now calling it
Conditional Group Rules
dbaron: I pulled @media into it since it seemed to fit, and 2.1 only
describes it in 2 lines
dbaron: Also includes @supports and @document
dbaron: It changes syntax by allowing @rules inside @media
dbaron: I think it's worth keeping Syntax and Cascading within scope,
even if we aren't committing to anything specific, so that
we can pull out and progress pieces of them
plinss: Need an item about regular snapshots, not just 2010
plinss: I also want paged media to move from low priority to medium
jdaggett: line layout should be medium, not low
Alex: I want CSS3 Floats
Alex: Floats and Exclusions
discussion of some positioning modules
no objection to line layout at medium
<jdaggett> yay
fantasai: maybe we should move Positioned Layout to low, since I'm not
sure we'll get to LC in 2 years
Tab: fine with that
Alex: Can we work on things in 2.1?
Bert: Charter allows us to work on anything as long as within scope for CSS
<Bert> -> http://www.w3.org/Graphics/SVG/WG/charter/2010/Overview.html
SVG draft charter
Bert: SVG draft charter has some overlap with us via the task force
Bert: We should make sure their high priority items match our high-priority
items
Bert: SVG charter notes things that are supposed to be joint work
Bert: Do we agree with all of those?
Vincent: There is CSS animations and Web animations, some consideration
of making them consistent
Vincent: Does that need to be a work item?
Vincent: Related to transforms, there are 3 specs for that
Vincent: I think the goal for everybody is to work on FX taskforce spec
Vincent: focus on convergence part
Bert: Our charter mentions SVG in two places, joint work for filters
and masking
Bert: Then the dependencies section, which mentions ....
Vincent makes a suggestion about a table or something
Vincent: Cameron was listing filters, compositing as something to
work with CSSWG
Vincent: Makes sense to coordinate
Vincent: Others were gradients, 2D, 3D transofrms, and web animations
Vincent: I think all topics are touched on in charters except compositing
Vincent: And from my end, only question is that we're clear on which
spec we're working on
Vincent: In some cases there's CSS spec, SVG spec, joint spec. Clear
which one we're focused on
fantasai: Who's editing the charter?
Bert: Chris? Not sure if he can
ACTION: Bert edit charter per notes above
<trackbot> Created ACTION-325
plinss: Anything else on Charter?
Regions Publication
-------------------
Vincent: So on the regions status, we have 2 documents css regions
and css exclusions
Vincent: For regions last we had a resolution during the concall
to publish a WD when the updated eidtor's draft would be
updated with comments incorporated.
Vincent: I sent that earlier this week
Vincent: Includes comments
Vincent: Everything that happend until the WG resolution to publish
is in the draft
Vincent: Next step is to publish the WD
Vincent: And discuss issues and resolve and prepare next WD
Vincent: Think that's pretty much what we need to do
Exclusions and Floats
---------------------
Vincent: For Exclusions we went from original spec and split
regions from exclusions
Vincent: MS has alternate proposal called CSS3 Floats.
Vincent: Plan is to merge spec
Vincent: I'm happy to work with whoever wants to work on it
Vincent: Scope right now for exclusions, there's issue of laying out
content into arbitrary shape
Vincent: Second issue is wrap around an arbitrary shape
Vincent: THen there's extension to float model and positioning scheme
Vincent: positioning floats with more flexibility
Vincent: Make float have arbitrary shape
Vincent: That's scope for current proposal
Vincent: Some of those issues are orthogonal to each other
Vincent: My proposal would be to do a new draft that covers all those
topics, and next time have a review of that document and decide
if some parts should be split into a different spec
Florian: howcome says we're happy that we're working on this and working
on it here, but it's too early to stop any spec
Florian: or override others
Alex: Neither we nor Adobe is planning to deprecate GCPM floats, unless
other floats do everything in GCPM floats
Alex: I think should be a single CSS3 Floats spec going forward not to
override GCOMP floats, but to make sure we have compatible models
Alex: We have new language for exclusions, e.g., we'll have difficult
time merging together
Alex: Better to put them together now
fantasai: And merge with CSS2.1 floats and clearance
Alex: In our draft we said, we had extension to CSS positioning
Alex: There are number of pages, but one value that we wnat to add which
is position: page, position thing relative to apge
Alex: Not sure it's worth creating a spec for just that value, but it
should go somewhere
Alex: One approach could be to create a CSS3 Positioning spec, that
includes abspos and all kinds of positioning from 2.1
Alex: Have an effort to make CSS2 positioning better defined
Alex: Arron is interested in that
<dbaron> (e.g., top/left/right/bottom: auto)
Alex: Not going to volunteer Arron to edit spec, but he was interested
in that activity
Alex: And having that spec
Tab: I'd be happy to take Arron on as co-editor, that'd be fun
Vincent: Should we have a resolution to move forward with new draft
that includes all current proposals and has scope that we
described.
Slide:
* content arbitrary shapes
* exclusions arbitrary shapes
* expanded float model
* expanded float positioning model
fantasai: Not sure about what you have on the slide, but what you
said earlier sounds good to me
RESOLVED: Make this spec as css3-floats
Vincent asks about publishing css3-regions
ACTION: Bert publish css3-regions as FPWD
<trackbot> Created ACTION-326
<alexmog> http://www.interoperabilitybridges.com/css3-floats/
dbaron: This stuff seems scary. Scarier than GCPM stuff.
dbaron: Just the notion of what flows around what, and not knowing
what floats you're going to have to flow around...
Alex: Yes, it is scary.
Steve: That's what I think is the hardest part. Kindof like compositing.
Have to define what makes up an entity
Steve: When we were discussing this in February, there was ...
interactions of floats from Apple
Vincent: Right now just asking to merge into new proposal. Not even
asking to move to WD.
Murakami-san: I have one quesiton about CSS3 Floats
Murakami-san: CSS3 Floats contains multicol floats, that spans multiple
columns
Murakami-san: That's now in GCPM
fantasai: We might consider splitting these into CSS3 and CSS4 later,
once they're merged and made consistent
dbaron: I'm concerned that we're working on too many big layout systems
all at once
dbaron: I'd rather get flexbox and grid and vertical text done first
Steve: I think the reason to do them simultaneously is to make sure we
understand the interactions
dbaron: exclusions I'm ok with, it's the positioned floats I'm concerned
about
Steve: exclusions are just positioned float
dbaron: It feels like a pretty big difference to me. Maybe I just don't
understand
Alex: Maybe you didn't read exclusions carefully enough
dbaron: Exclusions seems clear about what you're applying the exclusions
to and where it's coming from
Vincent: My suggestion would be to put the new draft together..
Vincent: I think you're right, some of these problems are fairly orthogonal.
We could adopt current float model and see how to adapt exclusions
to it
Vincent: Another feature is positioned floats, which you're concerned about
Vincent: I think there are various issues and they're not all as
objectionable
dbaron: I can see some ways to define positioned floats that aren't so
horrible
Steve: My understanding of Alex's use of float is an object that intrudes
on other object
dbaron: What bugs me about positioned floats is that the existing float
model has notions of document order, so wwith a float stuff
after it floas around it and stuf before it does not
dbaron: It also means that floats obey invariants wrt document order
wrt other floats
dbaron: This makes it relatively easy. And by relatively easy, I mean
one of the most complicated pieces of code in a layout engine.
dbaron: ... dynamically ..
dbaron: But maintaining positioned floats at arbitrary positioning,
where you have to track where it is in document order, and
which text comes after it and which text wraps around it and
which doesn't
dbaron: or you have floats affecting stuff before it
Alex: Can affect things before in document order, regarding what exactly
the dfinition is, that's going to happen
Alex: Challenge for us here is to come up with clear definition of what
it means and something implementable and something that can be
done without horrible perf penalty
Alex: But since it still does that, it's either GCPM floats that goes
to top right of page, or exclusions, or
Alex: The dependency backwards is going to exist.
dbaron: Part if it is that I really really don't like the absolute
positioning model for layout.
dbaron: I prefer Grid Layout
<dbaron> http://dev.w3.org/csswg/css3-exclusions/
<dbaron> http://www.interoperabilitybridges.com/css3-floats/
CSS Regions
-----------
Vincent: Are there topics for regions and exclusions..
Vincent: Here are the issues I have on the table
Slide:
- intrinsic sizing: height: 0 as well as width:0
- auto-sizing and containing blocks
- breaking rules and alignment with paged media and multicol
- integration with css grid layout and multicol
-regions styling
Vincent: ? had some use cases for [something]
Vincent: A lot of issues raised in CSS Regions exist already in paged
media and sometimes in multicol
Vincent: Something I'd like to talk about during this meeting
Vincent: Another thing Steve mentioned is interdependencies with other
specs, namely grid layout and multicol
Vincent: Would be nice to make this work with grid layout and multicol
Vincent: Some small things to do, integration
Vincent: E.g. addressing grid cell and display values
Vincent: Multicol doesn't have a way to address a column box, will be
needed to make it a region
Vincent: Have a demo of an implementation, one in Webkit and one
scripted impl of that
Vincent: Still a lot of concerns about it
Bert: By regions styling, you mean not just background, but also the
content of it?
fantasai: If you're going to do that, please also write the spec for
::first-line
Vincent shows an example
Vincent: So those are the larger issues.
Vincent: Smaller issues
Vincent: If you look at printed content, you get different widths
Vincent: We actually break down that content, and split boxes, and
they find themselves in varying size container boxes
Vincent: Regions make that very obvious, you really ned to work that out
Vincent: Issue of writing content from page to page is the same
vincent: also projection in the specs, at least in all I've ben able
to find, it refers to pages
Vincent: But the thing that's unique about it is on the computer the
browser has an infinite canvas, but projection is like printing,
and what it let's you do is having pages that you flip and
that's how you navigate your content
Vincent: conceptually some implementers do it this way, those are kindof
regions and you lay out content between regions that way
Vincent: multicol is another example of the same issue, you break down
content into set of containers. Regions is a variation on that
Vincent: It's still the same concept of having on one hand content that
needs to flow and of having different regions in the chain of
regions to flow content into
Vincent: And then the difference...
Steve: Point being that there are a chained set of areas into which a
continuous chunk of content is distributed in all of the regions
plinss: The issue with all this is that we've punted on different-width
containers, and we can't do that anymore
Vincent: Shared issues with all these models are the natural breaking
rules, this is common between columns and pages and regions
Bert: There are some differences where breaks between columns can be
less bad than between pages
plinss: Interesitng thing with region is wide region, then other region,
looks like columns
plinss: might want different breaking depending on what type of regions
you're breaking between
Vincent: Issue of forced breaks, that we should treat as overall in
general how does that work, for pages columns etc.
Vincent: talked about varying widht container boxes for pages and regions
Vincent: Region-based styling, should address it also for multicol etc.
if we address it
fantasai is deeply concerned about the number of tests that this will
all require
Vincent: Alan Stearns is working on that
plinss: Breaking text flow is easy, floats and tables are hard
dbaron: In theory you have that problem for multiple page sizes as well
plinss: goes back to my point
dbaron: You have two floats that fit side-by-side, and then flow them
on the second page they don't fit side-by-side, what do you do?
Alex: no good answer to that.
Alex: In every layout engine at MS, we had an approach that we do layout
on the first page we see these elements, and then continue that
layout onto the next pages
Alex: So that the table remains the same width on all pages
Alex: We never had a user-facing product that would actually expose
that functionality, so we don't have poof that that's the best
approach to the problem
Alex: So we need to experiment
Steve: XSL has this property for a long time, do you implement it
Murakami-san: Yes, we implemented XSL:FO
Murakami-san: With multiple regions with multiple, the region width is
changed when the page is changed. That requires
reformatting process.
Murakami-san: It's not very important for our product, but I think
it's hard to browsers that requires processing speed.
Steve: To summarize, it's doable but expensive
Murakami-san: We do expensive formatting.
Alex: I'm not convinced it's doable.
Alex: I'm convinced there is no optimal solution that will work, we'll
have to come up with some kind of compromise
Vincent: One thing that would be useful for moving along
Vincent: you were mentioning multicol
Vincent: On the float-breaking rules section..
Vincent: I took the CSS2.1 precedent and modified wording to accomodate
regions
Vincent: I know we need to make all these things work together
Vincent: One was the breaking rules. Tlaks about breaking properties
Vincent: Orphans and widows etc.
VIncent: fallback. I tihnk this needs to be reconciled and put in that
spec or somewhere else
Vincent: Talk about all cases where we have that issue
Vincent: 2 sections that are important here are the breaking rules and
the breaking properties
Steve: By breaking properties do you include widows and rophans?
Vincent: yes
Alex: decision to be made here, does this belong in regions spec, or
should it be a separate spec?
fantasai: separate spec
fantasai: affets columns pages equally
dbaron: I think the worst cases for breaking are actually abspos
Steve: Something has to be decided what they mean
dbaron: the others I can come up with something reasonable, but abpos
I have no idea what they should do
Alex: Maybe resolve right now that we come up with a name for breaks
or breaking spec?
discussion of specs
Steve: How about we stick it in Regions until we have a place to split
it out into
fantasai: make a separate section, note it will be split out later
Alex: What's a page?
(discussiong page break values)
Alex: With regions there's no way to tell which of the hierarchy of
regions is the page
Alex: Can have regions within pages, regions that span pages
Alex: region needs to understand that this region is on one page,
that region is on another page
Alex: Need to come up with a way of communicate that information to layout
Alex: region on one page, next region on another page
Alex: we have scenario where column break vs page break makes sense
from design point of view
Alex: I'm not sure I can come up with a compelling scenario where a
region break vs page break is important to have
Alex: Vincent has scenario where we create columns by creating regions,
in which case a region break is a column break but then
Alex: a page break is a higher-level break
Steve: Example Vincent shows, when he reduced point size of styled
regions, the heading at the top of the previous column
Steve: And that's where you'd want a region break
...
Alex: You can have regions within columns. is the column break smaller
or larger than the region?
fantasai: could be either
fantasai gives pathological example: regions 1 and 2 on page 2, with region
2 continuing onto page 3, region 3 on page 1, region 4 on pages 3 and 4
Vincent: There's clearly issues with breaks
Vincent: I think there's odd cases we should clarify what happens
alex: Nothing to guarantee that the sequence of regions and sequence of
pages are going in the same directions.
Alex: Could have region 1 on page 2, region 2 on page 1, and region 3 on
page 3
Steve: Question of how you would do that.
Steve: Pagination, you don't know how many pages you need, need a way
to add more pages when you find you haven't run out of content.
Steve: That's why page templates were separate from content, and rules
for how to choose a new page template as you walk down the content.
Steve: Basically you can't use named regions b/c you don't know the names
of the generated regions are (?)
Steve: You need to be able to refer to the next instance in this whole thing.
....
Alex: this is more complicated than I thought :)
Vincent: There is a concept of a set of regions in which you're going
to flow content, and that's nested
Vincent: The variations as we said before is, sometimes you will actually
generate regions as you go due to a template
Vincent: You have that as an option
(fantasai explained how to do a page break in alex's pathological case)
Steve explains fantasai's example
ACTION: fantasai define pagination behavior across different-sized pages
<trackbot> Created ACTION-327
<dbaron> (how to handle pagination of abs-pos with left:auto is fun)
Steve: To summarize,
Steve: There needs to be a mechanism for indicating intended containment
structure if you're going to define interaction between breaks
in container levels
Steve: Pages and columns, we know that columns have to be within pages.
But with regions we don't know that.
fantasai is not so sure that this is needed
Alex proposes something about using the CSSOM
Alex: How do you define a next page? Where do these pages come from?
Alex: We don't have a generic templating mechanism. don't know how soon
or if ever we'll define that in CSS
Alex: Ppl are going to be really creative in what they're going to use
Alex: Best we can do is give them CSSOM to let them figure out what the
content wanted there.
Alex: Where is that page template coming from?
Alex: If we add that object model to regions.. add .. to regions
Alex: There was a request for page size, page name
Alex: That will be way for somebody to write code that kind of thing.
Steve: That's one way of capturing intended
Alex: region break separate from page break
Vincent: Containment model, I could take that action item
fantasai: with multicol, you can reasonably assume that a col break wants
to break the innermost column box
fantasai: not so with regions
Vincent explains example of multicol with headers that break across pages
Vincent: Maybe tomorrow we could take smaller ones? Probably can be
sorted pretty quickly
Meeting closed.
Received on Friday, 10 June 2011 16:06:24 UTC