- From: Dennis Heuer <einz@verschwendbare-verweise.seinswende.de>
- Date: Wed, 17 Jan 2018 00:01:29 +0100
- To: www-style@w3.org
On Tue, 16 Jan 2018 12:34:20 -0800 fantasai <fantasai.lists@inkedblade.net> wrote: > On 01/15/2018 05:44 PM, Dennis Heuer wrote: > > On Mon, 15 Jan 2018 14:44:31 -0800 > > fantasai <fantasai.lists@inkedblade.net> wrote: > > > >>>> - - - - - > >>>> > >>>> Maybe (mere suggestions): > >>>> > >>>> 'fixed' should have been named 'fixed-in-viewport' or > >>>> 'fixed-within-viewport' or something like that. > >>>> > >>>> 'scroll' should have been named 'fixed-in-element' or > >>>> 'fixed-within-element'. > >>>> > >>>> 'local' should have been named 'not-fixed'. > >> > >> I agree the names are sub-optimal. Unfortunately when the > >> 'overflow' property was created, the CSSWG picked a behavior for > >> 'scroll' that imho didn't make any sense--affixing the background > >> to the scroll container rather than to its contents--and then we > >> had to come up with another keyword that meant “scroll with the > >> contents”. :/ > >> > >> But it is, alas, not something we can fix now. > > > > Deprecate the old keywords and give new ones. Because fixed and > > scroll behave compatible as long as they ain't followed by the > > optional keywords 'margin-box' ... 'content', only local is an > > issue. One can still support it for backwards compatibility. > > There is a non-trivial cost to adding aliases for existing CSS syntax > that is sub-optimally named. The cost is: > > * specification time > (this is minimal) > * implementation time > (this is not huge, but it takes away from other work) > * testing time > (ditto) As you see, no problem! > * mostly-unnecessary loss of backwards compatibility > (for pages which switch to the new syntax) > * author confusion > (are these keywords different or the same as the others? > Well, they are the same, but different in terms of browser > support...) > * author mental load > (more things to learn and memorize; more to teach and more > bloated reference texts) Huhh, that are arguments... 1) When sane layouters switch to css3, they do it the same way so or so. They put both css21 and css3 declarations in order, cascading. That is some work, but only if you switch. You are not enforced to switch to all new stuff immediately. If you use tools, they do it for you. So, what is the point? Also, as long as the overload works correctly, there is no inherent compatiblility issue 2) the author's confusion is now and gone with css3. That is my opinion. Also, books, wikis and blogs argue correctly about those switches already today. They 'insult' on the bad times and show how easy to use and understand it is now! They also give compatibility advices to stick to (mostly for HTML, but both is learned in company) 3) 1) If the author is new, he learns css3 and what he should cascade. He will not understand the old stuff and find that one a burden. But he will write this down once and for always and stick to his solution. Most manual layouters are copy-pasters. Not so much a problem. We all did this, isn't it! 2) If the layouter is aged, he knows how to read spec and will like the better support (I mean, lots of possibilities compared to the strange and stubborn 'fixed', 'scroll' and 'local'.) He will agree to it and put it on the list, for later switch! 4) Isn't rather compositing and stuff the overload? 5) The more sane the standard gets, and the more corner-cases are cleared, the better the development flows and the more happy the layouters are. Let time do it for us... > The last three are the biggest costs, as there are millions of authors > and users who are potentially affected. In some cases, where we think > there is a *very* significant benefit to a renaming, we will do it. > But in most cases we judge the costs to be not worth the (slight) > benefit of a better name. > > ~fantasai > > Regards, --------------------------------------------------------------------- Dennis Heuer einz@verschwendbare-verweise.seinswende.de
Received on Tuesday, 16 January 2018 23:25:08 UTC