W3C home > Mailing lists > Public > www-style@w3.org > June 2014

[CSSWG] Minutes Seoul F2F 2014-05-21 Part II: text-overflow: fade, Logical Properties, background-position -x/-y

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 13 Jun 2014 10:18:30 -0400
Message-ID: <CADhPm3ug8EqKHMqe4ZtYiDmNAHjzDmBcBcBa0=sdgmzngvtFVA@mail.gmail.com>
To: www-style@w3.org
text-overflow: fade

  - Discussion of potentially adding 'text-overflow: fade' led to a
    wider conversation about adding more overflow functionality
    that would cover this and many other cases.

  - There were a few potential solutions for a wider solution,
    but also most people felt that a text-overflow: fade keyword
    would likely still be necessary. Conversation will continue
    between interested parties.

Logical Properties

  - RESOLVED: Create ED of CSS Logical Properties

Background-position -x/-y

  - With both logical and physical properties, the handling of
    background-position -x/-y has become more complex.  There
    was no resolution of how to deal with it, but the current
    direction is spec physical with background-position-block
    and you specifying the direction.


Agenda: http://wiki.csswg.org/planning/seoul-2014#agenda
Scribe: dael

text-overflow: fade

  TabAtkins: I had a 5 or 10 minute topic from last night.
  TabAtkins: At least year's blink con one of the Bloomberg guys
             that does work on Blackberry asked me to propose a
             value for text-overflow that does a fade over the edge.
  TabAtkins: So when the thing overflows you don't kill characters
             for an ellipsis.
  TabAtkins: The name they're using is -blackberry-fade.
  TabAtkins: I think text-overflow: fade is good.

  hober: Is the fade configured?
  TabAtkins: Yeah.

  plinss: My concern is that is there is going to be a new paradigm
          next year. Can we do a generic way to handle overflow
          markers where someone could use a fade?
  hober: Like how I do a fade from 000000 black to transparent black?
  plinss: My point is can we get creative and come up with
          ::overflow or something
  clilley: Where the overflow defines and area that you can style.
  plinss: And the default is ellipsis.

  glazou: Can we just add a value for that effect?
  TabAtkins: If we had a way to config, given that we don't have a
             way to composite just the content there's no way...
  hober: Masking?
  fantasai: That gets into background. You just want text to fade.
  fantasai: The easiest is a keyword.
  plinss: But when we want a different effect, do we need another
  TabAtkins: Well if it's similar we just tack it on.
  TabAtkins: The obvious solution is eventually do a pseudo when
             it's needed.
  <clilley> krit mentioned adding an image.

  Rossen: One common request we get besides layout is that people
          want to use it for bubble or what have you, so we need to
          be able to attach other behaviors.
  fantasai: Yeah.
  TabAtkins: And that's even more true for block overflow.
  Rossen: This is more than just a layout issue. Eventually we put
          the power in the designer's hands.
  TabAtins: I agree.
  hober: I think that's a better long term way.

  TabAtkins: None of that solves that there is no way in CSS without
             new abilities to do a "Let's fade the content over some
            fraction" thing.
  Rossen: Well, what we talked about...
  TabAtkins: We have conceptual framework, but nothing that can be

  krit: Is it possible that instead of one keyword we have the image
        and that uses mask? That give more freedom.
  TabAtkins: Are there use cases for fading with an arbitrary image?
  krit: I can imagine it. There are different ways to indicate and
        that's platform dependent.
  TabAtkins: You mean adding an image, yes?
  clilley: If you use the image and use luminance.
  TabAtkins: You can't fade the content via the masking of another
  plinss: It seems we should fix that.
  krit: You can fade and mask just the text. If you use
        text-overflow and just use the image it's not an issue.
  TabAtkins: Maps instead of displays?

  Rossen: And how large is your image, krit?
  krit: You have to define that.
  Rossen: In the case of text-overflow what you would do when you
          layout the last word? You would have to work your way
          backwards to find the ellipsis.
  Rossen: Actual size is determined at layout and if you're just
          doing one generic image, how do you align?
  krit: How would you define the offset for gradients?

  TabAtkins: I'm still not clear, krit. I think you're suggesting we
             can spec an image instead of a string and have an
             option for use this image as a mask instead of as an
             image. Is that correct?
  <krit> yes
  krit: Yes.
  TabAtkins: That seems weird to me because it feels like jamming a
             special behavior in and if we're introducing something
             more than just a keyword it should be more general so
             that you can use an image as the mask of any element.

  fantasai: Do we want a pseudo for something like ::content and all
            you can apply is masking/filters? As a general thing?
  TabAtkins: No, we don't want that because...well, it won't solve
             the overflow because you can't tell what side the
             overflow is on.
  plinss: Yeah, that's orthogonal to the question.

  fantasai: Can overflow take two values?
  TabAtkins: Yes.
  fantasai: If we add image we can do that. If we let the image be a
            mask that solves it.
  TabAtkins: But saying you can do that for text-overflow, that
             seems an oddly specific way of generalization.
  TabAtkins: That's an odd place to stop. Either design something
             that works clearly or design the general facility
  fantasai: I'm in favor of the keyword regardless.
  fantasai: I would suggest we add fade to text-overflow.
  fantasai: We'll need a more general solution that has event
            handling and full styling, but even if we had that it
            would be awkward for this simple, straightforward case.
            We'd still want a keyword here.

  hober: You think a single keyword would be enough for most
         people's designs?
  TabAtkins: For most people, but allowing it to pass a length
             wouldn't be a problem.
  hober: People who have gone to the effort to create this already
         are the kind of people that want that level of control.

  glazou: The fade length is likely different on a small screen.
  TabAtkins: I've seen some long fades.
  fantasai: So you want to use percentage length?
  TabAtkins: Percentages and lengths.
  glazou: Adding length doesn't really fit. Fade should be functional
  TabAtkins: As a keyword and a function it should take a length.
  hober: Works for me.
  glazou: Me too.

  TabAtkins: We can discuss the greater generalization later.
  glazou: I've seen a text-overflow with flat text and rounding.
  plinss: It's a transform, right?
  glazou: It's a transform.
  plinss: People will want to do transforms. If we give them one we
          know they'll want a lot.
  hober: And if we get feedback it's good.

  plinss: I don't mind the keyword, I want to explain that the
          keyword creates these things and you can override that by
          adding these lines of CSS.
  hober: And you can describe the pseudo as something you can work
         toward and get at later.
  plinss: Let's explain it in terms of our primitives.

  fantasai: I think adding the keyword makes sense and we should
            work on the general solution. And having these specific
            use cases will help us get there correctly.
  TabAtkins: I think it's the ::inside pseudo Hixie tried forever
  fantasai: I don't think so.
  fantasai: We could spend the morning trying to figure out this
            problem. People want control over overflow, they want
            ellipsis in the direction of the block...
  fantasai: We always find that solving it takes time and we
            have time now.

  Rossen: We can look into using ::after { content: ... }
  Rossen: ::after
  fantasai: I don't think we want to do that.
  plinss: How does that interact with the overflow?
  fantasai: It's part of the text content that gets elided
  hober: It's the last part of the content.
  plinss: So that if you have content in ::after can cause the
  fantasai: If you have a long bit of ::after content a lot will get
            ellipsized, but if it's short...

  dbaron: What needs solving for block-overflow?
  fantasai: First is to have the block-overflow marker as part
            of the last line, and second is to have it after
            the last line.
  dbaron: I've seen the latter as fades.
  TabAtkins: When in JS it'll be centered on the last line.

  TabAtkins: The other requirement would be to be able to receive
             click events.
  fantasai: We need a way of defining events.
  dbaron: In some cases you'll only want click valid in some places.

  fantasai: I propose we take a break, get the awesome green board,
            and start doing examples.
  glazou: I don't think the green board will get in the elevator.

[break = 15min]
[break went very long due to productive side meetings]

Logical Properties

  fantasai: First issue is logical properties in general. There's
            four implementations - Webkit, Microsoft, Mozilla, and
            AH - and there's no spec.
  fantasai: When I wrote it the working group said I wasn't allowed
            to publish it (4 years ago).
  fantasai: We're proposing the take that spec and resurrect it
            separately and publish it as an ED with a FPWD shortly
  fantasai: Editors would be myself and Rossen with murakami doing
            some ghost-editing.

  fantasai: Further comments?
  hober: It's a great idea. Do it.
  dbaron: I may have comments when it exists, but I'm happy to have
          it exist.
  hober: If you check the UA stylesheet for right and left we
         clearly need it.
  Rossen: There's enough web content that it demands having this.
  Rossen: We don't want to go into technical details now.

  RESOLVED: ED of CSS Logical Properties

  dauwhe: Should we try and use logical properties when writing
  fantasai: I think all future drafts of layout should have logical
            and physical properties spec'ed together.

  Rossen: There's two exceptions, backgrounds and borders and
          exclusions. It was demanded that we name all the
          properties from the start.
  hober: So exclusions is only logical?
  TabAtkins: Well, we didn't have a way to mix.
  hober: So where webkit has physical and logical, the shorthand is
         physical. So are there exclusion shorthands that are
  Rossen: No. You have wrap-start, wrap-end and it's in the logical
          way of whatever we decide logical is.
  fantasai: And shorthands probably want a keyword to spec that
            it's logical.
  hober: !logical
  Rossen: We can have an option.

  TabAtkins: Do we want to defer discussion about order for four
             sides in a margin?
  fantasai: The one that starts block-start, inline-start, block-end,
  hober: Start, after, end, before should be the order.
  TabAtkins: Depends on if you're English-specific.
  dbaron: What fantasai said matches Arabic and Hebrew.
  fantasai: But that also gets you what's on the beginning half of
            the block to be set first.
  TabAtkins: It's going to have to be opposite way of the circle for
  fantasai: “Start” logically comes before “end”, so the shorthand
            should match that semantic.
  hober: I was hoping for, if I have a margin for lengths that's
         physical. If I put !logical at the end I don't see
         something different.
  TabAtkins: It won't happen. Either English is wrong and Arabic is
             right or vice verse.
  TabAtkins: And vertical modes are completely a mess. We can only
             bless one writing method with being identical in both
             physical and logical shorthands.

  TabAtkins: Also, we have precedent on the order with grid positioning.
  TabAtkins: Grid only uses logical.
  hober: I'm not convinced, but we can discuss this later.

  zcorpan: I agree with hober that it should be similar to the
           spirit of the physical.
  fantasai: But the spirit was lets go forward and if we have four
            directions, lets go clockwise. If you're talking logical
            you don't go start to end, you do start,start corner
  hober: In horizontal LR it would be odd if !logical made my
         margins float.
  TabAtkins: I don't understand why that's valid because if people
             have a differently direction-ed language they can argue
             for a different result.

  plinss: One property of the shorthand ordering is that if you leave
          things off, you get logical (reasonable) results as CSS
          repeats to fill in the missing values.
  plinss: That rule should be preserved.
  <dbaron> It's not pure repeating (for the 3 value case)
  hober: That will hold regardless of this choice..

  Rossen: Currently most content is in physical.
  Rossen: If you have a keyword that breaks this half the time...
  TabAtkins: So if someone is an idiot and converts to logical
             without thinking about it, your left and right will
  zcorpan: I think people will use the keyword because it's cool.
  hober: If you have existing content and want to make it flip to
         logical, it should be as easy as possible.
  Rossen: I can see libraries changing.
  TabAtkins: And the first time a library switches people will see a
             bug. You're positing a library that forces you into
  TabAtkins: They'd assume english and swap the values. You're
             assuming library authors are idiots.
  TabAtkins: There's a difference between one person and someone
             that writes a plug for 100 web pages. Are you writing a
             library and pushing without testing your result?
  clilley: Then people wouldn't use your library.
  TabAtkins: You want to make sure that the omitting arguments
             make sense.

  hober: If you have two values it applies to the start and end.
         plinss argues we shouldn't do something pathological.
  dbaron: plinss's argument is that of the first two arguments, one
          should be block and one should be inline.
  fantasai: And we're arguing that of the two inlines, start should
            be first.

  hober: I think the underlying issue is that the original clockwise
         choice was a mistake, but it's one we'll live with forever
         and I think consistency with that mistake is a good thing.
  glazou: Are we done with logical properties?
  Not quite.

Background-position -x/-y

  [photo of white board from dbaron for reference]

  fantasai: We can add background-position -x/-y, however it gets
            problematic once we add logical keywords.
  dbaron: To be clear, this is the day we have a 1pm-2pm that needs
          to be from 1pm-2pm which means we need to break for lunch
          in the next 10 minutes.
  fantasai: I'll present and we can ruminate over lunch.
  * dbaron notes that lunch will not consist of grass

  fantasai: The problem is we have a background-position property
            which takes two values (for simplicity).
  fantasai: They are all keywords. They are top, center, bottom;
            left, center, right. Pick one from each set of 3.
  fantasai: When you throw in logical values you can do this or
            choose from inline-start, center, inline-end, and
            then block-start, block-center, block-end, again
            pick 2 from each section.
  fantasai: But then how do you map that to the longhands,

  fantasai: There's a third case: pick one keyword from the
            physical directions, and a second keyword from
            an axis-agnostic logical direction, e.g. specify
            "top start".
  fantasai: If you have English that's the top-left, for Arabic
            the top-right, and for vertical Japanese the top-right.
  fantasai: You've already constrained the first dimension along
            a physical axis, so you then pick the second position
            along the opposite axis.
  fantasai: Let's say you have a sun and a fish background, you want
            the sun to be in the origin, but not to be scrolled off
            so you'd want that in the start corner, but in the top
            for sure.
  fantasai: So there's reasons to combine logical and physical.
  fantasai: This world with a combination of logical/physical
            doesn't map to the x and y axis.
  Rossen: We introduced background-position
  fantasai: inline/block

  <dbaron> case (1) is using only physical
           (top/center/bottom and left/center/right)
  <dbaron> case (2) is using only logical
           (inline-start/center/inline-end and
  <dbaron> case (3) is mixing one value from case (1) with
           (start/center/end) (note no block- or inline-)

  TabAtkins: In the same way we'd have an alias?
  fantasai: But we can't actually accept it as an alias.
  TabAtkins: You can alias after you figure out writing modes.
  hober: If you set margin-start and inspect margin-top?
  dbaron: So then the long hands let you spec combinations that
          can't be represented...
  hober: So the margin shorthand is if you have something global
         to the property line, the short hand is all physical or
         logical, but if you use the longhand you can mix.

  dbaron: So in your 3rd case of start-center-end they're values of
          x and y because they're not spec values of inline-start?
  TabAtkins: That's how I was thinking I would handling the
  dbaron: I don't quite follow the implications.
  zcorpan: If you are mixing the physical one, you can get into
           shorthand fine?
  zcorpan: So if you have top-start than it goes into position-y.
  zcorpan: The problem is if you spec both as logical?

  fantasai: There's an additional problem. In all of the other
            cases with logical properties, the initial values
            of the logical and physical variants are identical.
  fantasai: If they all are 0 and there's no conflict. But here
            with the initial values of the physical longhands
            will be top left, while the initial values of the
            logical longhands will be start start. That's fine
            in English where they are equivalent, but in other
            languages it'll be inconsistent.
  dbaron: And you need to know which one to use.
  fantasai: And you can't use the cascade because there isn't
            one if there are no declarations.

  TabAtkins: I say spec by fiat.
  dbaron: There's another way. If you have something spec'ed for
          one, if the winning is background-position-y you use that
          for x, but if the winning is background-inline that wins.
  dbaron: It could be two values but one gets overridden.
  hober: But with none?
  dbaron: We leave the current default.

  TabAtkins: So if we do fiat physical, if you spec background-position
             block and you spec in the direction, it should work.
  TabAtkins: I'm fine with that.
  dbaron: I'm okay. It's more complex than I was hoping.
  fantasai: Yeah.
  fantasai: It would have been nice to avoid the longhands.
  hober: It would be probably premature to resolve on resolving in
         this way since we haven't tried, but let's agree the
         initial spec should be this way and we'll alter if needed.

  [break = lunch]
Received on Friday, 13 June 2014 14:18:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:43 UTC