Discussion:
[css-backgrounds] Re:CSS Backgrounds and Borders Module Level 3 and border-attachment
(too old to reply)
Dennis Heuer
2018-01-13 13:51:39 UTC
Permalink
Gérard,

On Fri, 12 Jan 2018 17:27:05 -0500
Hello
It's embarrassing that authors hide communication behind third-party
systems, expecting participants to create accounts...
Dennis,
Realistically speaking, what would you propose instead as an
alternative to give feedback to CSS specifications editors? CSS
specifications editors can be reached by using a public mailing list
(available to all) under the control of W3C. That makes sense to me.
Any public discussion forum that has no rules, no registration of
some sort will easily become chaotic, ugly, spam-infested and useless.
Other authors put an email address into the document. I had to find
this list myself, not knowing if they WILL actually read it. I don't
like this separating behaviour... However, I wonder for a long time
why no ticket/bug system supports a way of registration like for
mailinglists. In case of BugZilla you even have to beg to get your
account closed by the admin. Actually, one could even send tickets via
emails written in wiki script. I just mean... But THEY don't want to.
They want you to have an account - and they want your data!

Sorry, not my day!
From my point of view, the description for 'scroll' should be the
description for 'fixed', and the description for 'fixed' should be
the description only for e.g. the body or the html element.
The <body> or the <html> element could be smaller and/or narrower
than window viewport. By definition, the <html> element does not
necessarily fills the height of the window viewport.
Eg
http://test.csswg.org/suites/css2.1/nightly-unstable/html4/background-root-008.htm
Works in my case. Actually, I'm shocked that HTML is not same as
viewport because this is what is said so everywhere, i.e. w3schools
asf. However, definitly, it should fill its own viewport and be same
with it. Why reaching outside (in an exposé of html pages or similar) is
unclear to me. But even then there should be a viewport element to reach
directly
- - - - -
'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'.
Interactive test on 'background-attachment': 'local' versus 'scroll'
versus 'fixed' values
http://www.gtalbot.org/BrowserBugsSection/CSS3Backgrounds/background-attachment-349.html
I guess that they just mixed up the paragraphs a bit. But you show
here what I criticize in general. If we stick to elements, we don't
need complicated names. If we break down choices to mandatory and
optional/additive choices, we get rid of conflicting settings. I'd
prefer keywords like 'fixed' and 'scroll' to be mandatory and related
to the addressed element, of which there have to be as many as there
are use-cases. Keywords like 'margin-box', 'border-box', 'padding-box'
or 'content' are optional and rather belong to a property like
background-clip.

This connects to a further strange thing in css: the border image that
can keep the 'middle-part'. I understand this so that then the border
image is a background image. I wonder if not the property background,
that allows the setting of multiple images, should set background and
border image, and the rest of properties for the border would just
add effects to it, like 'inset', which is a bit like 'emboss'. The
property border-outset I'd rather drop or turn into an
optional/additive set of values.
Interactive CSS 3 Background Tests
http://www.gtalbot.org/DHTMLSection/InteractiveCSS3BackgroundTests.html
Gérard
---------------------------------------------------------------------
Dennis Heuer
***@verschwendbare-verweise.seinswende.de
fantasai
2018-01-15 22:44:31 UTC
Permalink
Post by Dennis Heuer
Gérard,
On Fri, 12 Jan 2018 17:27:05 -0500
Hello
It's embarrassing that authors hide communication behind third-party
systems, expecting participants to create accounts...
Realistically speaking, what would you propose instead as an
alternative to give feedback to CSS specifications editors? CSS
specifications editors can be reached by using a public mailing list
(available to all) under the control of W3C. That makes sense to me.
Any public discussion forum that has no rules, no registration of
some sort will easily become chaotic, ugly, spam-infested and useless.
Other authors put an email address into the document. I had to find
this list myself, not knowing if they WILL actually read it. I don't
like this separating behaviour... However, I wonder for a long time
why no ticket/bug system supports a way of registration like for
mailinglists. In case of BugZilla you even have to beg to get your
account closed by the admin. Actually, one could even send tickets via
emails written in wiki script. I just mean... But THEY don't want to.
They want you to have an account - and they want your data!
Hm, earlier drafts always linked to the www-style mailing list. It looks
like the boilerplate changed to link to GitHub. It is good to link to
GitHub since that is the preferred forum currently, but www-style still
exists, and imho should be linked to as an alternative for anyone who has
a problem with using GitHub.
Post by Dennis Heuer
- - - - -
'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.

~fantasai
Dennis Heuer
2018-01-16 01:44:17 UTC
Permalink
On Mon, 15 Jan 2018 14:44:31 -0800
Post by fantasai
- - - - -
'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.
~fantasai
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.

Regards,
---------------------------------------------------------------------
Dennis Heuer
***@verschwendbare-verweise.seinswende.de
fantasai
2018-01-16 20:34:20 UTC
Permalink
Post by Dennis Heuer
On Mon, 15 Jan 2018 14:44:31 -0800
Post by fantasai
- - - - -
'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)
* 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)

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
Dennis Heuer
2018-01-16 23:01:29 UTC
Permalink
On Tue, 16 Jan 2018 12:34:20 -0800
Post by fantasai
Post by Dennis Heuer
On Mon, 15 Jan 2018 14:44:31 -0800
Post by fantasai
- - - - -
'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
* 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!
Post by fantasai
* 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...
Post by fantasai
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
***@verschwendbare-verweise.seinswende.de

Loading...