W3C home > Mailing lists > Public > www-style@w3.org > November 2013

[CSSWG] Minutes TPAC F2F 2013-11-12 Tues IV: Fill and Stroke on Text Decorations, Background and Borders 3, CSS3-text

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 21 Nov 2013 18:40:08 -0500
Message-ID: <CADhPm3u-wV8-=YVqrHCB+L_3j=u8z8RHhS2gUffmyGbyrwwjgw@mail.gmail.com>
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>&nbsp;<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

This archive was generated by hypermail 2.3.1 : Thursday, 21 November 2013 23:40:37 UTC