Re: [css4-ui] Scrollbar tracking control

On Jun 21, 2012, at 10:59 PM, "Sebastian Zartner" <sebastianzartner@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?
> 'scroll-top' and 'scroll-left' don't hit the point in my eyes (also not in JavaScript)

You mean it just doesn't feel right? I kind of like that things like scrollTop in JavaScript or jQuery would 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:

overflow: <overflow-attachment>

So, my version would be like this:

scroll-anchor: <scroll-left> <scroll-right>
overflow: <scroll-anchor>

> > 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 using here?

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 [1]. So somebody would have to write this to cover different writing modes:

I don't like that. It seems clumsy and awkward to me.

Received on Friday, 22 June 2012 15:54:05 UTC