- From: Rik Cabanier <cabanier@gmail.com>
- Date: Thu, 17 Apr 2014 16:59:28 -0700
- To: Dean Jackson <dino@apple.com>
- Cc: FX <public-fx@w3.org>
- Message-ID: <CAGN7qDDh9pACT=NkuL-DURgQ9kBmbeywxULdMRG_SRA=dzjwCg@mail.gmail.com>
On Thu, Apr 17, 2014 at 4:19 PM, Dean Jackson <dino@apple.com> wrote: > > On 17 Apr 2014, at 3:08 pm, Rik Cabanier <cabanier@gmail.com> wrote: > > > > > On Thu, Apr 17, 2014 at 1:42 PM, Dean Jackson <dino@apple.com> wrote: > >> As of https://trac.webkit.org/r167448 WebKit supports mix-blend-mode >> unprefixed. >> >> We did this knowing that we will be unable to implement the non-separable >> modes in the near future (hue, saturation, color and luminosity). We >> suggest these be moved to Level 2 of the specification. >> >> If they are not moved, we’ll probably put the prefix back on, because we >> don’t want to ship a non-prefixed incorrect implementation. >> >> [I don’t want to go into much detail here, but these effects are >> difficult to implement in our composited mode, and we wouldn’t want to have >> the content break as it becomes composited (which could be for any number >> of hard-to-determine reasons)] >> > > This sounds reasonable to me since you simply can't implement the spec > as-defined. There are also no shipping implementations so we're not going > to break any real world content. > It's unfortunate that we're dropping them, but hopefully we can add them > back in when OSX and iOS support them. > > > Great. We’re definitely not against the modes in the long term. > > I will send the spec back to LC and make the appropriate edits. > > Maybe we can flag the non-separable blend modes as optional? It would be > easy for authors to feature test this. > > > I think we should avoid specs with optional features. > > Also, “easy” feature detection is subjective, and all methods would > require script (unless you support @supports). > Yes, an author would have to set the property and then read it back to determine support. This would require script. > If these modes cause the property definition to fail, then that’s slightly > easy. If it works in software but not hardware, then it won’t be easy to > detect. > Yes, if a platform doesn't support it under certain circumstances, it shouldn't support it at all. Maybe making it optional introduces more complexity than needed for authors so I'm fine to leave them out for now.
Received on Thursday, 17 April 2014 23:59:57 UTC