- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 13 Jun 2014 10:18:30 -0400
- 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.
==== FULL MINUTES BELOW ======
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
keyword?
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
extended.
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
element.
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
ago.
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
ellipsis.
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
thereafter.
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
specs?
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
logical?
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,
inline-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
somebody.
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
swap.
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
logical.
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]
http://lists.w3.org/Archives/Public/www-archive/2014May/att-0008/dsc06433-fantasai-whiteboard.jpg
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,
background-position-x/y?
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
block-start/center/block-end)
<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
short-handing.
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