Re: [css4-ui] Scrollbar tracking control
Brad Kemper <brad.kemper <at> gmail.com>
2012-06-22 15:53:32 GMT
On Jun 21, 2012, at 10:59 PM, "Sebastian Zartner" <sebastianzartner <at> gmx.de> wrote:
> > > How about this:
> > >
> > > overflow-attachment-x: [normal | left | right] || <length> | inherit;
> > >
> > > overflow-attachment-y: [normal | top | bottom] || <length> | inherit;
> > >
> > > with <length> specifying the trap distance to the edge.
> > That is on the right track, but the name still feels long. How about
> > 'scroll-top' and 'scroll-left' as the property names?
just use the edge picked by the CSS author, and so using the same naming convention would make it easy to
understand and remember.
> and having a longer name isn't always bad as long as it is more descriptive as a short one.
Sure. But you have to admit, 'overflow-attachment-y' is pretty darn long. I don't think it is really
describing it that well. 'overflow-anchor[-x | -y]' would be better, since it it the part of the content
box that is anchored to the named edge while everything else gets pushed away from it. But I still prefer
'scroll-top' and 'scroll-left'.
> My proposal would also have the benefit that you could combine the value in the 'overflow' property and use
it as shorthand property. E.g. like this:
> overflow: scroll normal bottom;
Sure. You could still do that with my naming variation, since I am not touching the values. I think your
better argument is to have a 'overflow-attachment' shorthand property that combined x and y, like this:
overflow-attachment: <overflow-attachment-x> <overflow-attachment-y>
Which could then be shorthanded into 'overflow' as you suggested:
So, my version would be like this:
scroll-anchor: <scroll-left> <scroll-right>
> > And it could be writing mode dependent, if we also had those
> > keywords (er, begin/stop and head/foot?
> Yes, I didn't consider this before. What about begin/end for both properties? What are other properties
I think flex-box is doing that (start/end for both vertical and horizontal), but only because, uh, well, I
a, not the best one to explain that. I think because it needs to have a vertical and horizontal that are more
divorced from writing mode. Or something. Sorry I haven't been following that quite as closely.
> > Or whatever it is this week?).
> Of course it should be something consistent with other properties' values.
Agreed. I'm being a bit snarky because start/end are apparently well established for bidirectional
writing, but still hard for me to remember, because the opposite of "start" should be "stop" or "finish",
and the opposite of "end" should be "begin" (you even paired begin/end):
~ One can start smoking and stop smoking, but it is quite a different thing to end smoking.
~ One can start running in a race when the starting gun is fired, and stop running when they reach the
finishing line, but the race doesn't end until everyone is done or some time limit is reached.
~ books, articles, movies, and songs all have beginnings and endings. You can start or stop reading,
watching, or listening at any point, but the piece generally begins at the beginning and ends at the ending
(you can personally start reading, watching, or listening at the beginning, and stop reading, watching,
or listening at the end, or you could just start and stop reading, watching, or listening to a middle part).
Anyway, if you only wanted two directions, it would be start/end, because those keyword are established
for bidi. But I think you'd not get away with that. You need all 4 logical directions to be consistent with
most other things that (will) have four logical directions. The other two are under discussion to change
from before/after to head/foot.
> The alternative (when staying with left/right and top/bottom) would be to use the :dir() pseudo-class
. So somebody would have to write this to cover different writing modes:
I don't like that. It seems clumsy and awkward to me.