- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 15 May 2012 19:53:27 -0700
- To: "www-style@w3.org" <www-style@w3.org>
CSS3 Text
---------
- RESOLVED: Pending Jonathan Kew's okay, keep text-transform:capitalize
in its current form, with only an informative reference to
UAX29
- RESOLVED: Disallow combinations of values in text-transform for this level.
- RESOLVED: Changing currentColor to resolve at used-time is okay with
the SVGWG; we're just waiting on Color to be errata'd.
- RESOLVED: letter-spacing is kept as-is in the draft. A note should be
added about using padding to put extra spacing on either side
of an element, for the use-cases in which that is important.
- RESOLVED: Remove the 'avoid' value from text-wrap.
- RESOLVED: Remove the longhands for white-space.
- RESOLVED: Change overflow-wrap back to word-wrap. Allow CSS Property
Aliasing (future spec) to define that it aliases to
overflow-wrap. Next time Text revs, change the property
name officially and talk about aliasing.
- RESOLVED: Drop the full-size-kana value from text-transform in level 3.
- RESOLVED: Don't change "nowrap" keyword.
Writing Modes
-------------
- RESOLVED: Nobody cares too strongly, so fantasai should decide whether
to use "isolate bidi-override" or "isolate-override".
- RESOLVED: no UA dependent values for text-orientation
- RESOLVED: put our own table of behaviors for mixed-right and upright
values in the writing-modes spec until UTR50 stabilizes
====== Full minutes below ======
CSS3 Text
---------
fantasai: A few issues to go over.
fantasai: First is about justification and half-width characters.
ISSUE-98: http://www.w3.org/Style/CSS/Tracker/issues/98
fantasai: I'd like to close this as WONTFIX.
fantasai: Problem is a grid-style font whose characters are either
half-width or full-width, and you try to justify by putting
equal space between every character, the chars will no
longer line up.
fantasai: Koji recommended ignoring it, because these fonts are going
out of style, so it's not important enough to address right
now.
<fantasai> http://www.w3.org/Style/CSS/Tracker/issues/98
ACTION vincent to run the "justification of mixed full/half-width chars"
proposal past Nat. http://www.w3.org/Style/CSS/Tracker/issues/98
<trackbot> Created ACTION-470
ISSUE-240: http://www.w3.org/Style/CSS/Tracker/issues/240
fantasai: Next issue - should text-transform:capitalize apply to letters
after a hyphen or underscore?
jdaggett: What's the existing behavior?
fantasai: Dunno. The issue was "should we use UAX29 to determine word
boundaries?".
fantasai: I think the current spec doesn't define. It points to UAX29 as
being useful, but doesn't define explicitly.
dbaron: I think authors have complained about the inconsistency. I don't
know if their complaints were consistent in one direction or
another.
fantasai: There's definitely cases where UAS29 doesn't work well -
compare "l'enfant" with "don't", two words versus one.
fantasai: I don't think we have the correct rules yet, but I don't think
we need to be spending much time on it either right now.
fantasai: You simply can't rely on it to handle more than the simplest
cases correctly.
fantasai: So I propose closing it as WONTFIX, at least right now.
It's potentially useful, but it's very big, and low-priority
in my mind.
florianr: I think that Opera does something suboptimal, and I'd appreciate
a better ref, but I understand how hard it is, and how there's
probably just not a good answer today.
fantasai: A lot of the things that look obviously wrong in Kew's testcase
that look obviously wrong are already handled in the normative
text.
fantasai: For example, a lot hinges on the text saying "capitalize the
first *letter*". So you find the word boundaries, then scan
for the first *letter*, not necessarily the first character.
jdaggett: Have you checked with Jonathan Kew that this is satisfactory?
I'd like to verify that he's fine.
fantasai: Yeah, I can make sure. I think all of his examples were
covered by that sentence.
RESOLVED: Pending Jonathan Kew's okay, keep text-transform:capitalize
in its current form, with only an informative reference to
UAX29
ISSUE-242: http://www.w3.org/Style/CSS/Tracker/issues/242
fantasai: Next is combinations of values in text-transform.
fantasai: Previous draft let you combine values that weren't mutually
exclusive, like "capitalize full-width".
fantasai: There were several suggestions on the mailing list to not
allow these combinations.
fantasai: So I propose we disallow that. There's not strong use-cases,
and we can fix it later.
florianr: For context, I was one against the combining. I didn't
dislike combining, I thought the *draft's* way of doing it
wasn't good enough, and was hostile to later improvement.
florianr: I have a proposal for a better way, which is part of a
proposal for the next level.
RESOLVED: Disallow combinations of values in text-transform for this level.
ISSUE-244: http://www.w3.org/Style/CSS/Tracker/issues/244
fantasai: There was an issue about currentColor and inheritance - the
current behavior doesn't work for properties that inherit.
fantasai: I think we were waiting for SVGWG approval, which we got, so
I guess we want errata on CSS3 Color?
TabAtkins: Chris said he was okay with doing the errata, he's just been
unable to do it yet.
RESOLVED: Changing currentColor to resolve at used-time is okay with
the SVGWG; we're just waiting on Color to be errata'd.
fantasai: Next is an issue about where exactly you draw the letter-spacing.
fantasai: So if you say "I want letter-spacing in this element", is there
spacing on either side of the element?
fantasai: Current spec says no - the spacing between elements is given
by the common ancestor.
fantasai: A thread on the list said it might not be the right behavior
for emphasis in German and perhaps others.
fantasai: However, you can always add spacing with padding, while it's
hard to remove the letter-spacing.
fantasai: So I propose we close as WONTFIX, and suggest to use padding
for spacing around the word.
TabAtkins: I think this is fine - letter-spacing only takes <length>,
so it's trivial to apply the same <length> in padding right
next to it.
[a question from Liam that I didn't catch about the interaction of
letter/word-spacing]
RESOLVED: letter-spacing is kept as-is in the draft. A note should be
added about using padding to put extra spacing on either side
of an element, for the use-cases in which that is important.
ISSUE-243: http://www.w3.org/Style/CSS/Tracker/issues/243
fantasai: This is about the effect of graphical effects on text-decoration.
fantasai: We'd deferred an issue on how visibility applies to text-decoration
from CSS2.1
fantasai: I thought about it, and think that if you make an element
hidden, its decoration should disappear (even if the decoration
came from the parent).
fantasai: But what about text-shadow?
fantasai: It's clear that if *I* create the underline, I should shadow it.
But what if my parent is underlining me?
fantasai: And you have other effects - opacity, filters, etc.
dbaron: Those are both group effects, so they definitely affect the
decorations.
fantasai: Okay, so thoughts on this?
dbaron: I remember thinking about these things when I was fixing up the
Gecko text-decoration code during 2.1
dbaron: I thought we had a reasonable answer to this. I'd need to go
poking around about this to see what it was.
fantasai: Okay. I don't need an answer immediately, if you need to do
some research.
dbaron: There was a related issue with shadows - what color the underline's
shadow was.
fantasai: Okay, so no conclusion yet. I just need feedback.
szilles: Is shadow the only effect?
dbaron: The only things that should worry about is shadows and visibility.
dbaron: shadows are the same thing as text-decoration.
fantasai: Kinda, but shadows inherit normally.
dbaron: The decoration model is that its' *text* that draws decorations,
not the element, which is why they're consistent.
szilles: text-shadow is like what you can do with filters. We should
be consistent with shadows and filters.
fantasai: From the mailing list, Brad has a strong preference for not
shadowing decorations.
TabAtkin: And I had a preference for shadowing the decoration.
Steve's consistency argument favors shadowing it.
dbaron: Then the question is whether you use the shadow's color or the
decoration's color. I think the answer is to use the shadow's
color.
szilles: And that's consistent with filters too.
dbaron: Note that opinions can switch if you swap so that the shadow
is on the parent and the underline is on the child.
fantasai: no, that just inherits and works as expected.
fantasai: next issue is text-wrap.
fantasai: There used to be four values. We dropped one due to lack of
use cases.
fantasai: So now there are three values: normal, nowrap, avoid.
fantasai: The problem here is that the text-wrap property inherits.
fantasai: So if you have a bunch of nesting, and you set 'avoid' on
the outer element, you'll get 'avoid' on the children too.
fantasai: I think this is bad. My proposal is to remove the 'avoid'
value, and maybe pick it up for something else later.
fantasai: And then, once avoid is gone, there's nothing you can do
with these properties that couldn't be done with vanilla
white-space, so revert to white-space being a non-shorthand
again.
florianr: I think this is good idea.
RESOLVED: Remove the 'avoid' value from text-wrap.
RESOLVED: Remove the longhands from white-space.
fantasai: Last issue is about ruby.
fantasai: The layout model for ruby needs a ton of work, and it's
nowhere near stable.
fantasai: But there's one property that's simple and clear to apply
even if you hardcode your ruby markup, and that's ruby-position.
fantasai: In a similar way how we defined table properties even before
we defined table layout properly, we can say that ruby-position
can be applied to ruby, and controls whether it's above or
below your text.
fantasai: It doesn't define *any* details about alignment or sizing,
just its positioning.
jdaggett: What's the advantage of moving this?
fantasai: The advantage is that this property's definition is *done* -
it needs no more work.
jdaggett: You seem to be looking for a spec to stick this into.
fantasai: Yes, since epub already is using this, so we should pull it
into a proper spec.
szilles: Can we put this into Writing Modes? It seems to make more sense.
jdaggett: I'm uncomfortable with this controlling ruby when ruby
layout is undefined.
dbaron: One of the dangers with Ruby is that we've gotten feedback
from the Japanese publishers wanting particular behaviors,
and we're getting close to interop behavior on the *opposite*
of what they want.
fantasai: I cant' write the whole ruby spec right now.
TabAtkins: Don't be afraid of single-property specs.
fantasai: I could write a Ruby-Position spec and take it to last call
in two weeks. ^_^
szilles: Question, if we decide when we *do* write the proper Ruby
spec, that this property isn't useful, what will we do?
fantasai: I can't offer 100% guarantees, but I am quite sure that this
property will be necessary no matter what.
TabAtkins: Seconded, based on my own understanding.
plinss: I agree with you, Steve, in general about trying to spec ahead
of a good understanding of the model.
* sylvaing we can always put it in GCPM *cough*
plinss: But ePub is running ahead and possibly doing something that
might diverge, so we should control it now.
jdaggett: So epub has its whole ruby model?
fantasai: No, this is the only property they use. The rest of ruby is
just through markup for them.
jdaggett: Okay. I just don't like trying to spec ahead of the model.
plinss: I agree with the sentiment, but is that a strong objection?
jdaggett: No.
Liam: The XSL definition for this uses different property names.
Liam: [lists them]
fantasai: bopomofo was changed to inter-character to be understandable
to non-Taiwanese.
fantasai: We use the line-relative values instead of logical values.
<Liam> http://www.w3.org/TR/2012/WD-xslfo20-20120117/#ruby-position
Liam: [describes 'auto' behavior]
jdaggett: If we're going to change this property, I object to speccing
it now.
TabAtkins: I would prefer we don't claim 'auto' ahead of the proper
layout model.
fantasai: Okay, moving on. overflow-wrap versus word-wrap.
http://lists.w3.org/Archives/Public/www-style/2012Apr/0775.html
florianr: MS invented word-wrap and did it unprefixed. Everyone else
implemented it.
florianr: Not long ago we decided this was a bad idea, and tried to
change it to overflow-wrap.
florianr: I've changed my mind about whether it's good to do this.
I don't think it's a good idea in this instance to change
it to overflow-wrap.
plinss: New people are learning CSS everyday and not all of them already
know this. People in HP get confused regularly.
hober: Nobody implements the new name? With the same values? Same
behavior? What are we doing here again?
TabAtkins: I agree. It's a bad name, but it's *done*. If we want to
*alias* it, that's fine, but we should say that's what
we're doing and explain how to alias in the spec.
florianr: Agreed. aliasing isn't defined yet, but I have a good model
for aliasing defined in Opera.
florianr: But the code review for my "alias word-wrap" patch was
denied, with them saying I should tell the W3C to not do it.
dbaron: I think it's potentially harmful to have permanent aliases.
Gecko currently has none.
TabAtkins: What are you doing about page-break-* and break-*?
dbaron: Not implementing break-* yet. Don't know how we'll deal with
that.
plinss: Not everyone using CSS already knows CSS. Gotta think about
the future as well.
dbaron: When will authors actually prefer to use overflow-wrap against
word-wrap?
florianr: When you drop prefixes on overflow-wrap.
plinss: So the arguments against seem to be the same as the arguments
against any change.
TabAtkins: Specifically, the arguments are that the benefit is
sufficiently small that it's not balanced against the
pain of aliases.
dbaron: I'll say that I'm okay with this, but think that if we do more
than 3 rename-for-better-reading per decade, we're doing
something wrong.
* sylvaing_airport the bartender and I are cheering for dbaron
TabAtkins: I suggest we stick with word-wrap, let the Aliasing spec
define the alias, and then let Text pick up the alias
next time it's able to rev.
RESOLVED: Change overflow-wrap back to word-wrap. Allow CSS Property
Aliasing (future spec) to define that it aliases to
overflow-wrap. Next time Text revs, change the property
name officially and talk about aliasing.
<sylvaing> resolution exploded my head
<tabatkins> sylvaing, it's just "do the rename at a point that won't
slow down Text".
<sylvaing> i know. but it also says 'we had a name, we changed the
name, now we're changing it back so we can change it again
later'
<tabatkins> sylvaing Hah, true.
jdaggett: We have another important topic. We've talked about
text-transform:full-size-kana for a few f2fs, and we keep
going around and around.
florianr: Are you okay with doing @text-transform in level 4 if we
drop full-size-kana from level 3?
jdaggett: yes.
RESOLVED: Drop the full-size-kana value from text-transform in level 3.
ISSUE-246: http://www.w3.org/Style/CSS/Tracker/issues/246
fantasai: One more issue. white-space:nowrap has the least consistent
hyphenation in all of CSS.
fantasai: Flexbox also has a nowrap value. These *must* be consistent.
fantasai: So Alex and I were going to just make them both "nowrap".
fantasai: But Tab wants to make them both 'no-wrap'.
dbaron: There's the problem of authors 3 years in the future trying to
remember which is the one that also works in old browsers.
TabAtkins: The good one will be the new one, and the shitty one will
be the interoperable one.
[seems to be consensus to not change it]
RESOLVED: Don't change "nowrap".
<Bert> ('nowrap' is certainly the keyword I can never remember: is it
prewrap vs no-wrap or vice-versa?)
TabAtkins: Maybe I can just change "nowrap" in flexbox to "single" like
the old flexbox draft.
TabAtkins: I'm renaming everything anyway. By the time I'm done this
will be called the Ruby layout draft.
ISSUE-220: http://www.w3.org/Style/CSS/Tracker/issues/220
fantasai: Another issue. What do you do with ideo spaces and fixed-width
spaces at the end of a line? Do they disappear or stay? How do
they line-break?
TabAtkins: Those aren't collapsed as part of whitespace collapsing?
fantasai: No. And the question is what to do at the end of the line.
kojiishi: Feedback from Japan is that people liked FF/IE behavior.
kojiishi: Some liked the details of FF or IE better, but everyone
thought that they were both acceptable, and better than
the other browsers.
plinss: We're out of time now, unfortunately.
kojiishi: There's a mailing-list post in this. We can decide on this
later.
fantasai: Does either option make the Chinese happy?
kojiishi: I think so.
szilles: Feedback from Eric was that he didn't make that decision.
szilles: This *might* imply that the behavior is language-specific.
szilles: He was clear that UAX14 was right.
[disagreement on whether UAX14 says that linebreaks are possible between
spaces, and what it allows between characters]
<fantasai> it allows breaks between fixed-width spaces, just not U+0020
<fantasai> and ideographic space is indeed handled as ideographic character
plinss: Resolutions?
[no resolution - koji will propose something soon]
Writing Modes
-------------
ISSUE-200: http://www.w3.org/Style/CSS/Tracker/issues/200
fantasai: Currently only isolate and bidi-override are usable in combination.
Someone suggested that they aren't useful except in concert,
so we should combine them.
glenn: Previous these values were isomorphic to the unicode control
characters.
fantasai: They will be again - unicode agreed to add isolation characters.
We're just ahead of them.
fantasai: Previous we allowed "isolate" in combo with "plaintext",
but it turns out we don't need the ability to turn isolate
on/off with plaintext, it should just always be on.
dbaron: Every time I look at this, I get confused. That's not a good sign.
[discussion about their behavior]
fantasai: To be consistent, 2.1 should have had "normal | embed | embed-override".
[stop talking about the behavior]
TabAtkins: So it seems the current and proposed behavior are functionally
equivalent. The *only* thing is that you'll have
"isolate-override" instead of "isolate bidi-override".
dbaron: yes.
fantasai: [explains the values with a chart, to illustrate the axises]
OUTSIDE
strong | neutral
+----------------+--------------------+
embed | 'embed' | 'isolate' |
INSIDE -------+----------------+--------------------+
override |'bidi-override' | 'isolate+override' | <-- subject of issue
+--------------- +--------------------+
| 'plaintext' |
+--------------------+
szilles: When answering questions like this, I think we should ask what's
most useful for the authors.
fantasai: I think it's easiest to author with them combining.
RESOLVED: Nobody cares too strongly, so fantasai should decide whether
to use "isolate bidi-override" or "isolate-override" herself.
kojiishi: Another issue - I think we should add an auto value to
text-orientation.
kojiishi: UTR50 is taking longer than expected - I think another
6 months or more.
kojiishi: Right now we're in trouble because the behavior isn't defined,
but content is depending on some behavior.
jdaggett: I don't see the value of having a new value without a definition.
TabAtkins: We don't usually make 'auto' mean "whatever", it means
"magic that CSS doesn't control, but which is well-defined".
fantasai: I'm not sure adding auto would actually help us here.
kojiishi: If we leave it as it is, the world will be UA-dependent anyway.
TabAtkins: Do we expect impls to actually follow the explicit keyword
if we add this auto?
fantasai: I'm not sure the value is there. If people are authoring to
webkit's ipmlementation, they'll expect webkit's implementation.
fantasai: Nothing we do with keywords is going to change that.
Scribe: Shane
fantasai: If WebKit doesn't implement sideways values you can't do
explicit orientation control
koji: Japanese vendors of epub readers are using WebKit and writing
patches to implement sideways. But having trouble upstreaming to
webkit
jdaggett: so you're relying on the values working the way they are
intended to. In webKit they don't.
jdaggett: if I say upright, I don't always, based on code point and
font and other stuff
koji: upright works for asian users
jdaggett produces a counterexample
<hober> the bug that jdaggett is talking about:
https://bugs.webkit.org/show_bug.cgi?id=86071
koji: I'm talking about major asian use cases
koji: as long as you don't use mixed complex path, it just works
TabAtkins: This is going to be completely polluted anyway, probably
need to make a new property in a few years
jdaggett: epub is standardizing on a property that is undefined
discussion about whether this is about ebooks or the web
TabAtkins: because UTR50 isn't out yet people are just implementing
stuff they think is reasonable
TabAtkins: so if you can't wait for utr50, define something and we'll
fix it later
TabAtkins: write down a reasonable way of doing thing
kojiishi: problem is that defining behavior for arabic etc. is not easy
fantasai: that's fine, just define the bits you need
TabAtkins: just give arabic some value, doesn't matter what
TabAtkins: can provide use-good-arabic-vertical-text later
fantasai: or just swap it in if it's close enough
fantasai: I'll take an action with koji to do that
jdaggett: I don't get why we can't just wait for utr50
TabAtkins: because of pollution
jdaggett: how is that different to what happens elsewhere?
TabAtkins: they're not even trying to be similar
jdaggett: putting in stuff we remove later is busywork
TabAtkins: if we leave it then we'll just need to tear the property
down because it'll be too inoperable
jdaggett: I've proposed in the past an @-rule to do this
kojiishi: I've been saying to make this UA-dependent because that's
been happening for 30 years.
TabAtkins: jdaggett proposes an extension mechanism so stuff can be
defined in the future
Tabatkins I want to propose something simple so we have a chance at
keeping the keywords
florian: what's the chance of being able to keep them?
TabAtkins: non-zero
florianr: do you expect implementations do drop their heuristics and
adopt your simplified ones?
TabAtkins: yes, I would hope that happens
florianr: and worst case is we waste a bit of time drafting the
simplified heuristics
fantasai: even then our tables will end up being input to the UAX50
process
jdaggett: I think the UAs will keep doing what they are doing despite
what the WG does. Our best hope is for clarity - i.e.
"just wait until utr50 is ready"
jdaggett: if we give them an interim thing then they'll complain when
the real standard comes out
fantasai: the no change situation is that everyone will assume the
WebKit behavior is the standard
jdaggett: there is no standard. Things keep changing from version to
version of browser.
kojiishi: we can't file bugs with out something in the spec
hober: we can file bugs now - I filed one recently about unexpected
behavior
stevez: that just makes the problem worse because people will think
that WebKit is the standard
TabAtkins: so the alternatives are: 0% chance of working, will have
to burn down the prefixes, vs. people might get upset with
multiple updates
jdaggett: If koji and fantasai take the tables and put them in the spec,
I don't object. I just don't think it will solve anything
florianr: do you think it can hurt anything?
jdaggett: if vendors end up looking at it as a solution, it isn't,
because there's no consistency between different implementations
or versions of the same implementations.
jdaggett: but I do not think we should be adding values at all
fantasai: I agree with that
RESOLVED: no UA dependent values for text-orientation, and we'll put
our own table of behaviors for mixed-right and upright values
in the writing-modes spec
Received on Wednesday, 16 May 2012 02:54:00 UTC