- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 30 Sep 2013 20:01:39 -0400
- To: www-style@w3.org
- Message-ID: <CADhPm3sH2L7zPTpP=TP1nOZ33WOQAq35XBqoWF1eo_vkhW3-Lw@mail.gmail.com>
CSS Text
--------
- RESOLVED: letter-spacing: <length> doesn't restrict justification.
text-justify:inter-word; disables inter-letter
justification.
- RESOLVED: letter-spacing:normal; computes to 0.
- RESOLVED: Spec the dependence of text-align-last on
text-align:justify and mark issue for feedback on
shorthanding vs. not.
- RESOLVED: drop minimum/optimum/maximum values for word-spacing.
- RESOLVED: Keep 'text-align: start end' in, add an issue about
naming, and mark it at risk.
- RESOLVED: Take css3-text to last call pending resolving issues from
jdaggett.
Writing Modes
-------------
- Koji found a difficulty from the decisions made regarding tcy and
writing modes yesterday.
- RESOLVED: Drop digits 1
- RESOLVED: css3-writing-modes to Last Call when edits agreed in this
meeting are completed.
Animations
----------
- dbaron brought the group up to speed on the changes he had made to
the spec.
- The order in which events will fire and boundary points were of
particular concern, but it was decided that an e-mail
conversation and testing were the best way to answer the
outstanding questions.
=====FULL MINUTES BELOW======
CSS Text
--------
Topic: Letter-spacing
fantasai: CSS2.1 says that if you have non-normal letter-spacing, you
can't justify between grapheme clusters, only in space
characters.
fantasai: This is problematic in cjk, because they don't use spaces.
http://dev.w3.org/csswg/css-text/#letter-spacing
http://lists.w3.org/Archives/Public/www-style/2013May/0280.html
fantasai: We have several problems with the current spec.
fantasai: One is nobody implements it.
fantasai: If you set letter-spacing to 0 or something else, in latin
text, yes, you don't get any space. In cjk, no.
fantasai: So the text currently thinks "0" and "normal" are the same
thing.
fantasai: In word-spacing, "normal" *is* equal to 0.
fantasai: Those are the problems.
fantasai: Is there a reason not to change the existing spec?
Bert: Point 3 (word-spacing) is an unfortunate mistake, but unfixable.
Bert: I don't think that word-spacing and letter-spacing necessarily
need to inform each other.
Bert: Line-height also has "normal", and we don't compare them.
Bert: When you say "nobody implements it", you mean "..."?
fantasai: Implementations don't restrict cjk justification.
Bert: One change could be to change the meaning of the existing
values.
Bert: We could alternately add a value.
fantasai: That makes it unreasonably complicated for authors in a cjk
environment. They have to set justification, and also set
letter-spacing to something appropriate.
Bert: Not necessarily letter-spacing, just text-justify. They do that
already.
fantasai: No, "auto" (default value) just works. There's a less common
justification mode for cjk which they can opt into, but it
normally just works.
szilles: Restrict letter-spacing for a subset of scripts, and have a
cjk-spacing or ideograph-spacing for their separate controls?
fantasai: Doesn't work. I believe there's already content with
letter-spacing at a positive value that expect spacing on
cjk.
Bert: Why do people set it to 0?
fantasai: Because they think it's the right value, the default value.
It's unobservably different if you're not justifying.
Bert: I think I liked steve's proposal.
fantasai: Letter-spacing right now applies to cjk, and it must
continue to do so.
Bert: It's not that it doesn't apply. It's just that letter-spacing:0
lets you justify between cjk.
fantasai: Okay, so the proposal is that letter-spacing never restricts
justification for cjk, but non-"normal" values restrict
justification for latin and similar scripts.
Bert: How to define "similar scripts"?
fantasai: Dunno.
liam: If you have a passage of english text with a short passage of
chinese, and have justification turned on, those characters
could be spread apart?
fantasai: Yes.
fantasai: Spaces get priority over inter-cjk, though.
szilles: One way to distinguish language categories would be if they
use a word space.
fantasai: So thai would be with chinese, but korean would be with
latin?
szilles: Yes. If you have spaces, no need to do anything else.
koji: "Word space" in unicode is one of the non-script-specific
characters, so that doesn't tell us anything.
koji: We'd need to have a script-based property for this.
szilles: My concern is that there may be languages that use a script
with word space, and another language that uses the same
script without spaces.
fantasai: This seems overcomplicated. Already, "normal" and "0" just
seem confusing for authors.
Bert: The fact that there are two values implies that they're
different.
fantasai: A lot of people probably don't even realize there's a
"normal" value, and the fact that it looks the same as "0"
normally doesn't help.
fantasai: I think having script-specific behavior tied to "normal" vs
"0" is also confusing.
Bert: The best solution is to have some other feature to turn on
flexible letter-spacing.
fantasai: Things should work by default, and you're proposing that
justification doesn't work by default for cjk.
Bert: The spec already doesn't work for cjk.
Bert: So don't break latin, just add something for cjk.
fantasai: We're not getting anywhere, so I'm giving up for now.
szilles: Well, we at least came up with several possible solutions.
dbaron: Can we get a report of which implementers actually have a
normal vs 0 distinction right now?
fantasai: That's the issue - none of them do.
fantasai: If we make this change to the spec we're bringing it in line
with implementers
dbaron: I couldn't find a CJK testcase where an implementation does
inter-letter spacing for CJK justification
fantasai: You have to set [lang] correctly...
<fantasai>
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2521
<dbaron>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22width%3A%20207px%3B%20background%3A%20lime%3B%20letter-spacing%3A%200%3B%20text-align%3A%20justify%22%20lang%3D%22zh%22%3E%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6%E5%8C%97%E4%BA%AC%E8%88%AA%E7%A9%BA%E8%88%AA%E5%A4%A9%E5%A4%A7%E5%AD%A6
dbaron: I can't get Chrome to do any inter-character justification
even with [lang]
fantasai: I think Chrome needs you to set text-justify to something
else.
fantasai: Even if we change text-justify, the spec says that "0" means
you can't justify between letters. So we still need to
change something.
koji: I think what Steve is asking for is to have a way to disable
letter justification.
szilles: To have a way of tracking which languages use inter-letter
justification.
koji: We want today's behavior to not change, correct?
szilles: Close. I'm okay with...
fantasai: I think what makes the most sense is to make normal compute
to 0, as it does with word-spacing.
fantasai: And if we want a way to turn off inter-letter spacing, put
that in text-justify.
dbaron: I think using "letter-spacing:0" to prevent inter-letter
justification is not intuitive.
Bert: I think it's perfect. We don't need an extra property.
<astearns> +1 on dbaron's statement
szilles: We're trying to come up with a solution that matches today,
is reasonable to explain, and gives me the ability to do
tracking and allow justification using letter spacing.
dbaron: I think we have a set of justification controls that I believe
can do this already.
dbaron: And we have something that is not intuitive in the spec, that
doesn't match implementations, and that we'd like to get rid
of. I don't see what the problem is.
szilles: Evidence seems to say it does match implementations...?
szilles: Except for 0.
dbaron: That's what we're talking about.
dbaron: 0 vs normal.
Bert: The problem is that once I set a letter-spacing value, it
shouldn't do inter-letter justification.
Bert: It's nice that if you set it to 0, it also means no spacing.
fantasai: So proposal is that if you set letter-spacing to a <length>,
any length, you can still justify. (Plus a control on
text-justify that prevents justification.)
dbaron: But the spec currently says that setting a <length> should
disable justification. The implementers that do perform
inter-character justification don't follow the spec, and *do*
allow justification.
szilles: So right now we have one property doing both tracking and
justification control...
fantasai: What I'd like to see is that letter-spacing has no effect on
justification.
fantasai: If you want to disable justification, use text-justify.
szilles: So letter-spacing becomes tracking only.
szilles: And "normal" and "0" are the same.
Bert: Then we have a redundant value.
szilles: That's okay.
Bert: I don't want to change it in the cases where it currently works.
dbaron: We *have* found that some browsers do cjk inter-character
justification, and they violate the spec (doing it anyway,
regardless of letter-spacing). They don't do inter-character
for latin, so your case still works.
fantasai: So my proposal is that text-justify has "auto",
"inter-word", and "distribute".
szilles: None of those do what japanese does.
szilles: jl-req has a big table that does different things based on
the letters.
fantasai: That's "auto".
dbaron: Does it vary based on tracking?
szilles: I don't think it talks about tracking.
fantasai: "Auto" explicitly does that jl-req stuff.
steveZ: Fine, then I'm happy.
ChrisL: So is "auto" testable?
fantasai: Still no. jl-req is an informative ref.
<jdaggett> hmm, 'auto' as currently define *may* do JLREQ stuff
<jdaggett> there's no normative requirement for such behavior
* TabAtkins jdaggett, yes, that's what we're saying.
szilles: This is something where we want implementers to compete for
better quality.
fantasai: And there's a simple auto algorithm that they can do
instead.
ChrisL: So there's no way to explicitly say "use jl-req"?
fantasai: No. Japanese people have been kind and obsessive enough to
write down a very good algorithm, but *nobody else* does
that.
szilles: Japan has house styles that vary the jl-req table.
<ChrisL> and no way to say 'I implement jlreq but want the fast one
instead'
* dbaron wonders how this is related to the normal vs. 0 issue.
szilles: InDesign lets you control those things.
SteveZ: I'm fine with this.
liam: I wanted to make sure this didn't exclude arabic kashida
justification.
fantasai: We had a specific value, but killed it. "Auto" allows that,
and the spec has an example.
liam: Also, when doing copy-fitting, you often have multiple things
you want to list which controls what things are allowed to vary.
Maybe have multiple values here?
fantasai: I want to address that in the future. This doesn't block it.
[straw poll, the yay carries]
~10 in favor, Bert against
Bert: I don't understand why you change an 18-year old spec.
plinss: To match implementations, none of which match the spec.
RESOLVED: letter-spacing: <length> doesn't restrict justification.
text-justify:inter-word; disables inter-letter
justification.
fantasai: word-spacing:normal computes to 0. For consistency, I say we
do the same thing with letter-spacing.
Bert: I don't think there's a strong consistency argument.
TabAtkins: I think word-spacing and letter-spacing are reasonable to
tie in consistency arguments.
fantasai: Also, this means the computed value is just a length, which
helps.
RESOLVED: letter-spacing:normal; computes to 0.
Writing Modes
-------------
fantasai: A new complication with tcy was found by koji.
fantasai: <tcy><span>text</spa></tcy>
fantasai: Koji and I were discussing this, and right now when we
evaluate how much text to turn into a tcy run, we go across
the entire contents of the element.
fantasai: Whether or not you turn it into tcy depends on whether
there's an element boundary in it.
fantasai: If there's a boundary, we give up.
glenn: Remember that TCY is a japanese word, while
text-combine-horizontal is a property name. Consistency?
fantasai: Koji and I were thinking of changing this, so that we just
split up the text into runs between boundaries, then
evaluate tcy on that.
fantasai: So if I set tch:all here, I'll take the whole text run and
turn it into tcy.
fantasai: <tcy>a<q>bc</q></tcy>
fantasai: Here, "a" becomes a tcy (turning upright), and "by" becomes
a tcy.
Rendered like:
a
bc
szilles: This isn't extensible.
fantasai: Right, not extensible to including markup in the future.
fantasai: But it's simple (no lookahead), and makes the contents of
the tcy only ever be plain text.
fantasai: An implication of changing this is that if I have "digits"
as the value...
fantasai: <tcy>123<q>45</q></tcy>
fantasai: The first one wouldn't tcy, the second would. You'd get:
1
2
3
45
(with 1/2/3 being rotated)
szilles: I don't see what this solves.
koji: I think extensibility to markup should be a new value for the
tch property in the future.
szilles: There's more likelihood of accidental markup than purposeful
markup, and this one is affected by that accidental markup.
koji: Today it'll fail entirely with accidental markup.
szilles: Right, and that's probably a good thing.
szilles: You're assuming that the <q> has a meaning in those examples,
meaningfully breaking it into 3 units.
fantasai: Current spec gives up when you see the <q> boundary.
szilles: Right. Probably a better default.
rossen: The other option was to, if it's all inline, to take it as a
single tcy run.
rossen: So it'll still fail on blocks.
rossen: Which I think is reasonable.
rossen: I think "all" is pretty explicit and means "I want this whole
thing to be combined".
rossen: Presumably I know what I'm doing.
fantasai: What happens if I have <tcy digits>12<span>34abc</span></tcy>?
fantasai: 1234 is expected to form a tcy.
fantasai: But that's combining/breaking in an element.
TabAtkins: That's similar to bidi fragments, no? This is a problem we
already solve.
TabAtkins: (not saying it's a sane problem)
koji: We have implementers for 2 years, and we found these issues just
a few months ago. We already have lots of content using it.
koji: So we need something compatible with existing content.
rossen: Option C would still work in existing content. TCY together
everything that's inline.
koji: Can we come up with some spec text?
rossen: Yeah.
szilles: We already have a notion of "inline content" in the grammar,
so the spec can just say that the contents must be inline
content.
koji: ???
szilles: You're basically converting a float of max-content width, but
doing some other things - turning off some variants, etc.,
maybe do some kernings.
szilles: You'll have to specify all that anyway to be consistent with
implementers.
szilles: And if it doesn't fit in an em, scale until it does.
szilles: Clearly not ideal, but I'm not sure we have much of a choice.
dbaron: I think we do have the choice to do simpler things that don't
work in every edge case.
szilles: What do you buy? You're using code you already have.
dbaron: That's not always simple.
fantasai: Rossen and I were discussing problems with fragmenting the
inlines.
fantasai: For example, if you have logical properties that you want to
cascade and resolve, you can't do that if part of the
element is horizontal and some is vertical.
fantasai: Rossen suggested that you start forming tcy, and if there's
an unclosed element at the end, you give up.
fantasai: Here you end up with a single fragment that has 2 different
writing modes and that's worse than bidi
TabAtkins: [doesn't understand why this is different from what happens
in bidi fragments, but whatever]
[discussion of details]
<Bert> (Does <tcy digits2><em>abc1</em><span>2de</></> makes "12"
horizontal?)
<TabAtkins> (given their current suggestion, no - that's two unclosed
elements.)
<TabAtkins> (given the earlier suggestion of just using fragments,
yes, it would)
[more board scribbling and mumbling, too small, fast, and confusing to
minute]
fantasai: We did decide we had an issue about "digits" having to check
outside its boundaries, to make sure that a run of digits
within the element isn't contiguous with a larger run of
digits starting outside.
israelh: In "abc<tcy>def</tcy>", what would happen?
israelh: I mean <tcy>a<span>bc</tcy>.
rossen: It would work - the span would both open and close within the
run.
fantasai: We were hoping to keep this relatively simple, which is why
we had a non-inherited property.
fantasai: Now it's getting more and more complicated.
dbaron: It feels like this is already the complicated appendage to the
spec, which is now getting more complex.
dbaron: We agreed to stick on this complicated appendage because it
was considered essential for some use-cases...
dbaron: But do we really need to address every tcy case in this level?
szilles: Figuring out which subset to address is where we seem to go
aground.
fantasai: We started with just plain text...
dbaron: And then you said it wasn't enough.
koji: I'm fine with plain text with inherited values.
koji: But what I just said gives bad results for the a/bc case.
israelh: Do you see things like i^12, or whatever?
koji: I see people doing H_2O or CO_2 using horizontal writing mode in
an inline-block
koji: I do see that, or "CO_2", etc. but you can just use
writing-modes and inline-blcok for that.
szilles: If I put properties on an inline, do you turn it off?
fantasai: You inherit the all, and it takes effect on the inner span,
not the outer.
szilles: That's not extensible.
fantasai: Right. You can use inline-block to do *anything* in tcy, it
just doesn't do automatic compression.
TabAtkins: Until we do copyfitting, which'll address that.
fantasai: The other solution going forward that koji said, is a new
display value "character", which does try to do compression,
dots, etc.
fantasai: That would let us do everything you want to do with this
property.
fantasai: This lets us do all the use-cases so far. You can even do
CO_2 if you use the unicode subscripts.
fantasai: You can use inline-blocks for anything else, and in the
future we can get even better.
szilles: I don't like the fact that it's not extendable.
koji: We intended to do that. But we're designing for as simple as
possible right now, and don't exclude expansion in the future.
fantasai: ...so new design is inherited property.
fantasai: Consistency argument is that "digits" takes a run and looks
for continuous characters of a given type.
fantasai: But only on a text run.
fantasai: Consistent.
<TabAtkins> "digits" or "all".
fantasai: "all" is just like digits, but with any character.
szilles: It really isn't like that at all. For digits, you don't need
explicit markup; this needs explicit markup.
rossen: Right, you normally want to avoid markup. "all" just fills in
the holes for things like CO_2.
israelh: To the extent that we keep it consistent with what we have
right now, it'll be easier to understand. If we go beyond
that...
israelh: ???
israelh: When we go beyond what we can compress in a single line,
we've already established that it fails. So it's okay to
fail, from an authoring perspective.
rossen: So I think we converged to 2 choices.
rossen: 1 is to keep inheriting. Break when you see element
boundaries.
rossen: This'll make most cases that koji says work, and the "digit"
value work.
rossen: Simpler to implement, maybe a little more confusing to
understand. Potentially not extendable.
rossen: 2 is to go for more elaborate combining whee we allow crossing
element boundaries.
rossen: But then we need more smarts to think about if there are
unclosed elements, etc.
rossen: Likely harder to implement. Potentially more understandable to
users.
rossen: But I'm sure with enough mucking around we can always create
some element combinations that fail us.
rossen: So it's simple reimplementation but maybe some rarer cases not
working, or more complex implementation with some exotic cases
working, but we don't even know if it's the right "working".
[howcome just left; Tantek left a few minutes ago]
fantasai: (1) text-only, inherits
dbaron: Are there still multiple variants of (1) ?
fantasai: I have one in my head that I think is good.
fantasai: (2) only inline content (previously C)
fantasai: And (1) is A+D
6 for option 1
(fantasai, Rossen, Koji, Florian, dbaron, Tab)
2 for option 2 (Israel, SteveZ)
Bert abstains, can't make up his mind
<hober> and many, many abstentions
fantasai: Koji and I will spec up A+D and we'll come back to the
group.
RESOLVED: Drop digits 1
[Short Break]
Animations
----------
Scribe: Fantasai
plinss: What's the status with jdaggett?
plinss: We'll return to text if jdaggett appears
Shane: At F2F in Tokyo, I offered to get back to group with regards to
implementation progress that we made on the new T&A cascade
that we resolved on,
dbaron: I just got it into the spec this week, though some bugs in
that.
Shane: We don't have any problem with it, there don't seem to be any
major issues.
Shane: Some questions, though.
Shane: One part of implementation that was sub-optimal:
Shane: The issue is we've said that when you specify a transition on a
property that is inherited and the inherited value is changing
due to transitioning, child transition should not start
dbaron: I thought we resolved the opposite.
dbaron: My understanding was that we resolved...
dbaron: Resolution I have is in minutes at
http://lists.w3.org/Archives/Public/www-style/2013Jun/0682.html
<dbaron> A, C, D, E from
http://lists.w3.org/Archives/Public/www-style/2013Mar/0297.html
with modified part B
dbaron: We resolved to accept A, C, D, and E from this with a modified
part B.
dbaron: That's the edits I tried to make this past weekend.
dbaron: Part D, I guess, is where I said that, although it falls out
of the way I specified part A, or something else.
dbaron: Idea there was that if you have an inherited property that's
inheriting through a tree and you have multiple places in that
tree
dbaron: That specify transitions
dbaron: Then you will get all of the transitions.
dbaron: It may produce undesirable results, but it's what you asked
for.
Shane: We're happy with that approach, a lot easier to implement that
than suppress child transitions.
dbaron: One conclusion from that discussion was to give up on
suppressing transitions there.
krit: If you have inherit from ?, thought it was already specified
from the beginning that we resolved values before staring
animations or transitions.
krit: We resolved all the inheritance values before we start the
transition, so you don't have 'inherit' keyword.
dbaron: 'inherit' isn't a computed value, so that's not a problem.
Shane: I have a list of 5 questions, but we don't have to go through
those now.
dbaron: Anything likely to benefit from discussion?
Shane: When do we fire events? Are events asynchronous?
dbaron: When transition events fire?
dbaron: I don't know that we have a resolution on it, but I think it's
important that the script that runs as a result of
TransitionEnd event run before the Refresh that would have the
"no transition running anymore" style data.
dbaron: Don't do a screen refresh.
dbaron: Can't avoid script getting access to styles.
dbaron: But really want to avoid screen refresh between update to
style data and sending TransitionEnd event
Shane: Does a transition end on the screen refresh that first ...
dbaron: Asking > or >=?
dbaron: I don't think we've actually defined that.
Shane: Couple that question with timing statement you just made, then
if you were to say that TransitionEnd on the first frame in
which the final property value has been displayed, and the
transition effect must happen before the next round.
dbaron: Final property value is tricky with step transition functions.
dbaron: Could we say perhaps that, talk about that hypothetical
transition you'd have if your timing function was step-end?
dbaron: Makes a change only at end of transition
dbaron: Think that in Gecko we will fire the TransitionEnd event
essentially while we're doing the style updates
dbaron: In order to do the refresh for that value.
dbaron: If you have a step-end() timing function, and have
TransitionEnd on it, and use TransitionEnd to set it to some
other value, think you should never see the end value of that
transition. I would hope.
Shane: No, I think you should.
Shane: Otherwise, taking the step-end, if you chain based on
TransitionEnd, you'll never see any value until the last
transition ends.
dbaron: I was using "see" too loosely...
dbaron: We would fire the TransitionEnd event at a point where the
script will see the end value, but we haven't yet repainted
the screen for that value.
dbaron: So if you make another style change right then, it'll take
effect before we do any repaints. Not 100% sure about that.
krit: Might be desired in this cas
Shane: If you want to time two animations... to be perfectly smooth,
then you... I guess it also ties into whether we consider
transitions end-exclusive or not.
dbaron: Spec is not very clear on this stuff.
dbaron: Not entirely sure on this stuff. Not sure we should make it
clear for this version or not.
dbaron: If we figure out something we can agree on
dbaron: Worth writing some tests for this stuff and seeing what
happens.
Shane: We would be quite happy to not tie these questions down now and
wait until WebAnimations spec has been reviewed, and then in
the next level of CSS Transitions and Animations, adopt
whatever conventions Web Animations has provided.
dbaron: I'm certainly ok with waiting.
dbaron: Don't necessarily want to commit to waiting for web
Animations.
hober: Right.
dbaron: Not all that concerned that this will be a critical issue for
interoperability.
Shane: ...
dbaron: It's probably worth seeing how interoperable things are.
dbaron: I definitely had mental model of what boundary conditions are.
dbaron: I don't know if that agrees with your model, and spec doesn't
have a model.
Shane: Web Animations model is ... that a sample only belongs to one
animation or another ...
dbaron: That is the model I used in implementing CSS Animations, I
believe.
dbaron: For repeating animations.. though not entirely I think.
dbaron: Think what I did for repeating animations, I considered all
the repetition cycles, if right at boundary, would use start
state of next repetition than end state of last animations.
dbaron: But for last cycle, would still use value from animation.
dbaron: Don't remember if there was a good reason for that.
dbaron: Essentially what I did for animations, it included both end
points.
dbaron: Picked second iteration over the first one.
Shane: Given that model, when do the events fire?
dbaron: At the boundary point.
Shane: After style has been calculated, but before screen refresh?
dbaron: In Gecko only fire events as part of our refresh cycle.
dbaron: It would fire after style calculation.
dbaron: Would need to look more closely at code to see what changes
would take effect in observer.
Shane: Does that mean another style update could be triggered?
krit: Looking at SVG animations, it is always end-exclusive.
dbaron: Ok, I will make note to myself to see what happens if we make
ours end-exclusive completely, and see what that breaks.
Shane: A little concerned about that approach
Shane: If an event fires such that ...
Shane: Interrupted, then we can't really do chaining properly.
dbaron: If an event fires when?
Shane: ...
Shane: Step-end
Shane: No change, no change, no change, then jump
Shane: Never mind.
Shane: We currently coalesce iteration events if there are multiple
events between frames.
Shane: You okay with that behavior?
Scribe: krit
dbaron: As implementer I would not really care.
dbaron: Maybe we can discuss over email?
Shane: Sure
Shane: One other thing:
Shane: Provide a negative animation delay and pause
Shane: So that we can hit particular points and test these.
Shane: I think we can build a nice conformance suite
Shane: And think Gecko passes our test suite.
Shane: Is there anything missing that we should test?
CSS Text
--------
Scribe: dbaron
fantasai: text-align and text-align-last; last issue on
text-combine-horizontal (if we have a better name)
fantasai: The issue is interaction of text-align and text-align-last,
and whether one should be a shorthand of the other
Bert: and whether there should be a text-align-first
fantasai: Or we could just have 2 properties (text-align-all and
text-align-last) and all can take 2 values to say what the
first line should do, but I don't have a strong opinion on
that.
fantasai: I think we've discussed this a couple of times, don't have a
super good answer.
fantasai: The main difference in behavior is if you set 'text-align:
justify; text-align-last: justify' and then later in the
cascade want a particular paragraph to be 'text-align:
center', the last line will still end up being justified.
fantasai: Then we could do what IE does, text-align-last only takes
effect when you have text-align:justify
fantasai: If you go from center back to justify, then the first
text-align-last is still taking effect. Do you want that, or
do you want these text-align declarations to clear out the
first one?
fantasai: That's the main interaction issue.
fantasai: There's also -- jdaggett wanted to be able to specify
text-align: justify-all and have that just work instead of
having text-align-last
fantasai: But for back compatible we still need text-align-last
fantasai: so if we want to make this work we need it connected --
a shorthand
fantasai: Last consideration: somebody on the mailing list wanted to
say last line alignment matches the rest, without caring
what it is.
fantasai: If you want justify-all to work it needs to be a shorthand;
if you want the ability to explicitly defer last to match
others, it needs to not be a shorthand.
Bert: If we have just one property, just text-align, and no
text-align-last
fantasai: We have a backwards compatibility issue because people are
using text-align-last. In IE6, and old CR.
Rossen: at least
fantasai: We know MS is going to continue to implement
text-align-last, but seems like we're not going to have the
shorthand option.
fantasai: ... if we want to be compatible with ???
fantasai: Have 2 implementations, Microsoft and Mozilla.
Bert: Seems like what IE is doing is the best, just honoring last when
text-align is justify
Rossen: That's what word also supports.
ChrisL: Put it in the "Applies To" line.
fantasai: I thought word used something else.
Alan, Rossen: Word gives you the option, only applies to the last line
if justified.
<ChrisL> applies to the last line of elements where text-align has the
value justify.
fantasai: Considerations are: cascading behavior - both solutions
handle 'text-align: center' overriding -- but if elsewhere
set text-align:justify does it resurrect the old
text-align-last?
fantasai: Can't have justify-all value vs. can't have value for
matching the rest.
fantasai: And an expectation of shorthand behavior from property
names.
fantasai: Comments?
Tab: No opinion.
fantasai: If we add first line justification, then it would probably
be a keyword on text-align.
<astearns> I'm for option B - text-align-last only applies if
text-align is justify
fantasai: If text-align-last is not shorthanded we probably wouldn't
do a text-align-first property because it would have
horrible cascading (and if we had a shorthand they should
both be in the shorthand).
fantasai: Bert and jdaggett prefer not having text-align-last and just
using text-align for everything.
fantasai: That would have been better.
peterl: Can we deprecate text-align-last?
Bert: Maybe I'm inconsistent, but in this case...
Bert: but I don't think we should do that; it's been in a CR. One of
those mistakes we make once in a while.
peterl: I'm not saying take out of spec; leave it in spec and mark as
deprecated.
Bert: Do you have a use case for text-align-last with anything else
than text-align: justify?
fantasai: I don't have a strong opinion right now, although before I
was pretty convinced we should do the shorthanding.
peterl: I'm not happy about the legacy issue, but that's life.
Alan: Since we don't have a ??? use case for doing the right thing,
but we don't have anything ???. Leave it as it is with MS's
behavior until somebody gives us a reason to make a change?
peterl: Will need to change if we want text-align-first, would make
sense to have shorthand.
Alan: Are we planning to do that now?
peterl: No, but we should at some point
[nobody seems to feel strongly]
?: I defer to jdaggett?
Rossen: When we discussed this a couple months back, the query we did
over roughly 2 million documents came back with ... something
between 3-5% used text-align-last.
peterl: Any tests for value of the property, or just presence?
Rossen: I don't remember how I wrote the query... maybe checking for
value other than inherit.
peterl: So it included some cases where value had no real effect
Rossen: I think so.
Rossen: I wanted to see if <1%
peterl: But it could also potentially drop if most were setting to
initial value or something that has no effect.
peterl: If there is no strong opinions, leave it as is?
dbaron: How is it?
fantasai: Spec says they're totally independent properties.
peterl: What does Gecko do.
fantasai: Completely independent.
fantasai: AntennaHouse also implements
fantasai: Spec the IE behavior, and if somebody prefers shorthand they
can raise an LC comment and explain why.
RESOLVED: Spec the dependence of text-align-last on text-align:justify
and mark issue for feedback on shorthanding vs. not
* oyvind re animations tests, there are some old ones in opera
incoming/ that I didn't get around to inserting the spec
reference links into yet.
fantasai: I'm out of issues on css3-text.
Bert: Can we add the poetry behavior keywords to text-align:
first-left first-right?
fantasai: A little concerned about doing that ... I'd do it as
start-first.
Bert: Too difficult for users.
fantasai: Always correct.
fantasai: The only use case is start-first.
fantasai: I think it's obvious.
Bert: Those are words only people in the WG understand.
Bert: Maybe 'poetry', not 'start end'
Koji: If people don't understand 'start end' then we need to discuss
Florian: ... Beating them looks hard.
Bert: I'm not sure if it's only based on the direction. If that's
indeed the case than a single keyword would be enough.
fantasai: Actually, there's 2 things I want to drop from the spec
currently:
fantasai: (1) 'text-align: start end'
fantasai: (2) word-spacing can take up to 3 values defining minimum
optimum maximum; we don't have any implementations and would
prefer to drop and figure out justification limits when
we're in level 4.
Bert: Do we want to have limits or do we want to allow other
algorithms as well?
Bert: I'm ok with dropping it, not sure we should add it back in
afterwards.
fantasai: I think we should drop it until we have a clear idea what we
want for that.
Koji: Seems like the consensus is to drop.
RESOLVED: drop minimum/optimum/maximum values for word-spacing.
Bert: I'm not sure about dropping 'start end' value from text-align
fantasai: Main reason I want to drop is not because I don't want to
handle the poetry case, but because I want to figure out the
clearest syntax.
fantasai: This is just putting two keywords, not super-obvious what
that means.
fantasai: Maybe it makes sense to have some other keyword to express
that instead.
Bert: I'd like it to be a single keyword, not two keywords.
Bert: 'poetry' would work for me.
fantasai: I think that's too specific; I might use it for code.
[discussion]
fantasai: Poetry in general is not aligned like that.
peterl: Maybe research to see if there's a name for that?
fantasai: I want to drop largely because don't have good syntax for it
that's obvious.
Bert: Two-sided, continuation?
Alan: Any implementations?
fantasai: No,
Alan: I think we should drop it.
Peterl: We're trying to go to last call soon.
fantasai: Unless there are objections.
peterl: That's not alone a reason to drop; because it's not
implemented -- could mark at risk
<Bert> (I think alan was talking about min and max on word-spacing,
wasn't he?)
<astearns_> Bert: I was talking about dropping the poetry thing.
Alan: To play devil's advocate, ...
peterl: Keep in, put issue about naming, mark at risk?
fantasai: "This needs to be renamed at last call or it gets dropped"?
Bert: At some point I want the feature that inserts an > on every line
but the first.
fantasai: I want to check with jdaggett, and check with him on
text-align stuff.
fantasai: So I will make edits and do the write-up and if people here
are happy with it we can go to LC unless jdaggett wants more
changes.
<Bert> (left square bracket is actually more likely than angle
bracket)
RESOLVED: Keep 'text-align: start end' in, add an issue about naming,
and mark it at risk.
peterl: Do we want to resolve for LC now, or wait for edits and
jdaggett's feedback?
fantasai: I would prefer resolution, even if it takes another cycle,
so we can publish if things are ok.
RESOLVED: Take css3-text to last call pending resolving issues from
jdaggett.
fantasai: Any open issues on writing modes?
Koji: text-combine-horizontal naming only
fantasai: Plan is for writing modes to go to last call once we have
all the edits done.
peterl: Any concerns with that?
florian: Maybe not the last last call?
hober: But we want the feedback, thus ok with doing it now.
peterl: Are people comfortable going to LC without seeing edits?
RESOLVED: css3-writing-modes to Last Call when edits agreed in this
meeting are completed.
fantasai: I'll post to www-style with the edits so people can look and
give a week or so, and then publish.
Meeting closed.
Received on Tuesday, 1 October 2013 00:02:09 UTC