- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 21 Nov 2013 18:40:08 -0500
- To: www-style@w3.org
Fill and Stroke on Text Decorations
-----------------------------------
- This topic was deferred for now.
Background and Borders 3
------------------------
- Fantasai reviewed the issues remaining after the edits to borders.
- The topic of ensuring animating border-radius received a lot of
discussion with the decision being made to create examples that
show the possible solutions.
CSS3-text
---------
- The changes to auto hyphenation were discussed, including when soft
hyphens should be available.
- Another issue discussed was one raised by DigiPub asking if
text-align should become a shorthand for text-align-last. It
was decided that fantasai will e-mail a summary of the issues
for discussion at the next telecon.
- RESOLVED: We won't rename text-indent: each-line
- The last issue was in regards to letter-spacing applying to grapheme
clusters.
=====FULL MINUTES BELOW======
Fill and Stroke on Text Decorations
-----------------------------------
krit: I had hoped Tab would be here -- he could call in, or we could
delay the topic.
<TabAtkins> Calling in is a giant fail.
<TabAtkins> Never worked yesterday.
fantasai: We haven't got around to adding it to the spec.
krit: I'm fine to defer it
<fantasai> r12a, we'll want to discuss Text soon, let us know if that
works for you or you have other constraints
<fantasai> kennyluck: ^
<fantasai> starting with css3-background for now
* kennyluck coming
<r12a> fantasai, ok heading down there
Background and Borders
----------------------
<leaverou> http://lists.w3.org/Archives/Public/www-style/2013Apr/0109.html
fantasai: We had some substantive edits to this over the last year.
fantasai: We wanted to publish a LCWD and
fantasai: Get it back into CR after.
fantasai: One other issue was raised -- two.
fantasai: Andrew Fedouniak raise an issue that if you have a spread
radius on box shadow, and border radius is very small like
0.1, you run into rounding differences between
implementations.
fantasai: Because the spec says that at 0, the corners are sharp when
you have a spread.
fantasai: If it's non-zero, the corners get curved by the radius.
fantasai: It wasn't the best idea to have discontinuous behavior.
fantasai: But that's been in the spec for a while.
fantasai: And implemented for a while.
* dbaron recalls raising this issue sometime previously, perhaps?
<TabAtkins> dbaron: Yeah, that led to the wiki page that now says
"DON'T DO THIS".
fantasai: Maybe have a none keyword for border-radius, and that would
mean sharp corners -- that's the initial value?
fantasai: With 0 you could get the rounded behavior.
fantasai: The downsides of that is the initial value would be
detectable in the OM.
fantasai: If somebody set border-radius to 0 and had a spread radius,
their spread would no longer be square.
fantasai: 3rd detectable case is you can no longer animate from the
initial value to some other border radius value.
fantasai: Those are the 3 detectable differences.
fantasai: Lea and I both thought it would make sense not to make a
change to the spec.
fantasai: We want to see if the WG had other opinions.
dbaron: I would complain if we made the initial value not animatable.
zcorpan: If we do the keyword thing I don't understand why we couldn't
animate it.
dino: Transition from none to 5?
zcorpan: So?
zcorpan: What's the difference now?
zcorpan: You can animate from a square to round.
fantasai: This is the point:
fantasai: You can animate from 0, but 0 would no longer be the initial
value.
zcorpan: We could specify that animating from none would mean the same
as 0.
zcorpan: I don't understand why that is impossible.
fantasai: You could say as soon as you step away from none, it can be
animated.
dbaron: I say this despite that spread is kind of silly, but we could
make it continuous in other ways.
dbaron: E.g. we could say something like the amount of additional
rounding you get --
dbaron: Normally the radius of curvature of the outer edge of the
spread is the sum of the border radius and the spread value,
dbaron: So you get concentric circles or ellipses.
dbaron: You could intsead say that it is the max of that and double
the border radius, or something like that,
dbaron: To cap that effect,
dbaron: And thus make it continuous.
dbaron: It's probably a bit silly though.
fantasai: No comment on that...
plinss: I'd be in favour of an approach like david describes to avoid
the discontinuity.
plinss: I don't think we're helping anything by having none,
plinss: Still would be discontinuous as we step off it.
leaverou: It would be good to see some examples to see.
leaverou: I could make some.
fantasai: Let's say we can solve the animatable problem.
dbaron: I don't want to mess with the values of border-radius,
dbaron: I think it's important to leave them as they are; more
important than any spread use case.
dbaron: The thing I'm proposing is purely related to spread.
dbaron: I think we should leave the spec as it is.
fantasai: Any other comments on this?
krit: If we don't change the values, can we still animate it in the
future?
fantasai: You can animate it today.
krit: Leave it to 4?
fantasai: We'd need to errata 3 in that case, as we're changing
behavior.
bert: I have a strange idea for making it continuous.
bert: The outer edge of the spread: rather than making the corner the
sum of the border-radius and spread, just make it the same as
the border-radius.
bert: Maybe it looks too small.
leaverou: It would look horrible.
leaverou: There was a bug in webkit,
leaverou: Lots of complaints about it.
<TabAtkins> Yeah, the "right" way to spread things is indeed to
increase the radius by the amount of the spread. That's
how you do curved borders, frex.
<sgalineau> we can mitigate the discontinuity for some range of
spreads; once a spread is large enough there will always
be a point where the corner looks sharp and the spread
rounded...
<TabAtkins> (In reverse - the inner curve is equal to the outer curve
minus the border width.)
dbaron: I think it's not that bad for large spreads, but just when the
border radius is similar in magnitude or larger than the
spread.
fantasai: One thing we can do is go make some examples, to show off
your suggestion.
fantasai: If that seems reasonable we can change how spread behaves
near 0 border radii,
fantasai: Or not make a change.
fantasai: The next issue was the expansion of shorthands.
CSS3-text
---------
fantasai: There are two minor things on auto hyphenation.
fantasai: One was if hyphenation was turned on, and you have no
appropriate resource, is the UA required to hyphenate or
turn on auto hyphenation?
fantasai: I think the answer to that should just be yes,
fantasai: Since that was unclear in the spec.
dbaron: The appropriate resource implies known language?
fantasai: Yes.
fantasai: If you have a soft hyphen in the word, the text we inherited
was that that takes priority over auto hyphenation.
fantasai: Some implementations mix soft and auto hyphenation.
fantasai: If the auto is one point away with soft hyphen, it might
choose the auto one,
fantasai: Which doesn't make sense.
fantasai: I propose if there are soft hyphens, you only hyphenate
there, not auto.
richard: I wonder if there are languages with words so long you
wouldn't want to do that.
fantasai: If you want to put soft hyphens, you should put them at all
points in the word.
simonsapin: Can you break more than once?
krit: Yes.
richard: If you only had one soft hyphen, you'd be taking away the
other break points in a long word.
richard: It'd need to be clear that's what's happening.
richard: Sometimes you copy text and it has soft hyphens in it,
richard: And you're not aware.
richard: Not sure that's what people would expect.
richard: I don't know whether that's a significant objection.
bert: People who are used to TeX/LaTeX, that's how it behaves,
bert: So there is precedent.
rossen: Same in Word.
alan: And InDesign.
rossen: It's a well known behavior.
dauwhe: We discovered implementations that allowed auto hyphens as
well as soft hyphens, and that confused users.
dauwhe: If you're going to the effort of adding soft hyphens, that's
the most important thing.
plinss: I think if people put a discretionary hyphen it's because they
don't like what the auto hyphenation would do.
plinss: Otherwise you'd need to put ZWNBSP between all other
characters to disable.
dbaron: Another use might be adding soft hyphens for implementations
that dont have auto hyphens,
dbaron: And only on words where they notice where words are long.
astearns: That's a mistake.
astearns: You should place them on all places they could occur.
richard: There's no issue about existing text that's now going to
break is there?
dbaron: People have to explicitly enable the auto hyphenation.
dbaron: I think the resolution is fine, just wanted to point that out.
dauwhe: The only implementors I know that has this problem is not used
by millions of people.
richard: I'm convinced at the moment.
fantasai: There was one relatively significant issue with text align,
text-align-last.
fantasai: We got feedback from digipub working group.
fantasai: One comment was a suggestion that text-align be a shorthand,
fantasai: And perhaps there should be a separate property for first
line alignment, and then text-align could become a
shorthand.
fantasai: Another thing Bert asked me yesterday was, what if I want to
justify the only line of a paragraph?
fantasai: It wasn't obvious that you should use text-align-last.
fantasai: So while it is the last line, it's the only line, it doesn't
seem a logical place to look for that feature.
fantasai: That makes more inclined to consider text-align being a
shorthand taking justify-all,
fantasai: Rather than it be an independent property.
fantasai: It seems usability would be better if we do that.
dauwhe: I was confused by text-align when I first encountered it.
dauwhe: That it affected lines in the paragraph with line breaks too.
astearns: That's about the break, not this property.
fantasai: That aspect wouldn't change
fantasai: Sometimes we use a forced line break because there wasn't
one in the text.
fantasai: And we don't want the text before the line break to use
text-align-last.
fantasai: In other cases, you do want the text-align-last behavior.
dauwhe: I think it's a UA problem.
fantasai: It's a line breaking problem that should be handled with
ZWSPs.
dauwhe: They'd add letter spacing so you don't have a big gap.
fantasai: My proposal is we do the opposite of what we said in Paris;
fantasai: Make text-align a shorthand.
astearns: Didn't we determine the resolution we had in Paris was it's
the behavior that Word, InDesign has?
fantasai: It's not about that.
fantasai: It's about an interface problem on the CSS side.
fantasai: Is text-align-last an independent property from text-align?
fantasai: Or is it a longhand?
fantasai: Either way, you get various aesthetics.
bert: The issue is we had an implementation of text-align-last that
would sometimes give different results.
fantasai: We looked at content compatibility and determined there
wouldn't be a problem.
fantasai: At the F2F I was ambivalent,
fantasai: About which way to go,
fantasai: But I'm finding these usability problems.
kennyluck: Is this issue related to adding text-align justify-all?
fantasai: Yes, if we want text-align:justify-all we must make
text-align-last a longhand of text-align.
fantasai: Any other comments on this issue?
<dbaron> I'm in favor of making text-align a shorthand containing
text-align-last.
<kennyluck> (I am not very convinced that 'text-align: justify-all'
implies that 'text-align' should be a shorthand, but I
support whatever would make 'text-align: justify-all'
in.))
fantasai: There was a comment in the message from Markus that Bert
forwarded,
fantasai: Two days ago.
fantasai: My recommendation is to go the shorthand route.
fantasai: I can write a separate thread email if people want.
fantasai: I'm still waiting on i18n's comments anyway,
fantasai: I'm happy to discuss this at the next telcon.
plinss: In that email can you refresh our memories and a comparison?
ACTION: fantasai to mail www-style with the text-align shorthand issue
<trackbot> Created ACTION-597 - Mail www-style with the text-align
shorthand issue [on Elika Etemad - due 2013-11-19].
koji: text-align: each-line renaming,
koji: To each-paragraph, or after-break,
koji: I have no opinion,
fantasai: The problem with after-break is it also applies to the first
line.
fantasai: I don't think it's a better name.
fantasai: My first concern about each paragraph is that first the use
case is really about logical lines,
fantasai: Lines of code, poetry,
fantasai: Which wraps to multiple physical lines.
fantasai: Those are not paragraphs in any sense of the word.
fantasai: Second is that a paragraph is for HTML thought of as <p>
fantasai: This would be having units of a paragraph within a <p>
fantasai: My inclination is not to make a change here.
kennyluck: My question is the use cases for logical lines, why don't
you use padding?
fantasai: Because it allows you to indent each line hanging, say,
fantasai: The first line is not indented, but all of the lines that
line wraps to would be indented.
fantasai: Also it's typical for long lines of code,
fantasai: Which are wrapped due to the page width.
fantasai: Any other comments on that?
RESOLUTION: We won't rename text-indent: each-line
koji: Second issue, for line break behavior CSS requires to honor
UAX14
koji: After a NBSP, a replaced element -- UAX14 defines it to be
GL+CB.
koji: The other pair is CB, which CSS does not require to honor.
koji: Is there a break opportunity between the two?
<kennyluck> the case is basically this <input> <input>
fantasai: We should do that on the list.
koji: The last one from James Clark,
koji: He's saying that letter-spacing applying to grapheme clusters is
a bad idea.
koji: He's raising a few examples, Thai, other complex scripts, that
sometimes letter-spacing should not be applied between grapheme
clusters.
koji: Or one grapheme clusters should be split into multiple glyphs.
koji: He's not suggesting how to fix this, but just raising some
examples that don't work.
fantasai: I think the way I'd fix that would be to allow the UA to
modify the unit used for letter-spacing and justification in
what way is typographically appropriate,
fantasai: And leave that not defined any further.
fantasai: We'd start with UAX14, and then tailor as appropriate as we
find it.
fantasai: Either in UAX29 or css-text.
koji: I agree with fantasai.
koji: I replied saying this:
koji: I want to make sure the WG is fine to base on grapheme clusters,
but allow script specific modifications if needed.
richard: My guess; it's a worse idea not to use grapheme clusters most
of the time.
richard: If you start splitting off acute accents from Es etc., you'll
have a big mess.
fantasai: Any other comments?
fantasai: koji and I will continue to make comments.
fantasai: We'll come back with DoC after resolving these and getting
i18n feedback.
fantasai: The action for text-align we can discuss at the next telcon.
richard: I should point out we asked for an extension due to the
Unicode conference.
[Break]
Received on Thursday, 21 November 2013 23:40:36 UTC