W3C home > Mailing lists > Public > www-style@w3.org > February 2015

Re: [css-backgrounds] Add opacity to <bg-layer> definition

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 20 Feb 2015 14:27:19 -0800
Message-ID: <CAAWBYDCr0=feyMg-+3=VzwXyv=4WemN0iadMmZy1Gfh+eDwTpQ@mail.gmail.com>
To: Axel Dahmen <brille1@hotmail.com>
Cc: www-style list <www-style@w3.org>
On Fri, Feb 20, 2015 at 12:45 PM, Axel Dahmen <brille1@hotmail.com> wrote:
> AS I just wrote, I’m not on a quest to convince others here. Just
> suggesting. I leave it to others, more acquainted with the different CSS3
> specifications, to decide whether my suggestion is useful and time saving.
>
>> "Tab Atkins Jr."  schrieb im Newsbeitrag
>> news:CAAWBYDDMbZ22E=vL6WbyJ31wk6H3xWP=rv_9mLX=1hkB-7v+gw@mail.gmail.com...
>> On Wed, Feb 11, 2015 at 11:53 PM, Axel Dahmen <brille1@hotmail.com> wrote:
>>>>
>>>> Use an abspos with 'opacity' and "pointer-events: none;", with
>>>> 'transform' if you want to rotate.
>>>
>>> That would not only involve adding an additional block element, but also
>>> would involve a number of rather complicated CSS from all different specs
>>> of
>>> CSS. Morever, there is no rotate() angle definition in the CSS spec
>>> that's
>>> defining a rotation angle that's dynamically rotating an image to reach
>>> from
>>> one corner of a box to the opposing corner of that same box.
>>
>> The argument that "I need to look at multiple specs" doesn't seem very
>> realistic; you need to do that already to handle all the various
>> aspects of CSS in your page.
>
>
> Yes, you are right, but this doesn't apply to a single atomic feature.

What's an "atomic feature" to one person or one page isn't necessary
"atomic" to other people or the underlying language.  It's not a goal
to support every thing that can be reduced to a simple English concept
with a correspondingly simple syntax.

>> You're right that there's no way to dynamically compute the rotation
>> angle to stretch between the corners; the closest thing we have to
>> that is the magic angle computation of corner-to-corner gradients.
>> But most watermarks I've seen are either at a 45deg angle, or roughly
>> stretch from corner-to-corner on a page of known size, which you can
>> compute or just vaguely guess at yourself.
>> Note that your suggestion is just for an <angle>, which won't
>> dynamically compute a corner-to-corner rotation either.
>
> As we know from the linear-gradient property, the actual angle changes
> depending on the viewport, may it by resizing the browser window or by just
> printing a web page. So a more dynamic solution would be very appropriate
> here.

If the element is much longer than 1:1 aspect ratio, it's often *much*
longer, and a diagonal becomes nearly vertical, and not what you want.
If you want a 45deg angle, or the angle that would hit the diagonal on
a piece of paper, just use that directly.  Having a watermark exactly
line up with a diagonal does not seem to be a very common design goal;
adding a feature just for that would probably not be worth it.

>> "It's only a tiny, little, thin mint."
>> <https://www.youtube.com/watch?v=HJZPzQESq_0> ^_^
>
> As I just wrote to Sebastian, I'm trying to simplify the standard. I'm not
> trying to blow it up. And I believe it's sensitive to add such simple
> feature.

Again, adding new features does not make something simpler.  It might
make some *use-cases* simpler; if they're sufficiently common, then
the simplicity of the solutions averaged over the space of all
use-cases might get better, and be worth adding a new feature for.
But every feature makes the language more complex, regardless of how
well-argued it is.

In this case, there are several fairly simple ways to achieve your
goal, several in pure CSS.  Watermarking over content is not a very
common use-case (I personally only see it in stock photo examples,
where it's baked into the file and thus not relevant to this
discussion), so adding several new features to one of the most
complicated parts of CSS is probably not worthwhile.

>> > That said, CSS has become a Medusa of different specifications, >
>> > partially
>> > overlapping each other. I believe it's time to consolidate all those
>> > different ideas into one straight specification.
>> That doesn't reduce any complexity, it just puts all of it in a single
>> document that takes longer to load.
>
> Not at all. As you know, the HTML5 specification is split into several
> pages, too. I'm actually a bit confused about your argument.

If a spec in multiple pages is okay, then just go to
<https://drafts.csswg.org/> and pretend it's the Table Of Contents for
the All-Inclusive CSS Spec.  It's lacking an all-inclusive index, but
we're working on that.

~TJ
Received on Friday, 20 February 2015 22:28:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:01 UTC