New issue
Advanced search Search tips

Issue 108972 link

Starred by 44 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature


Show other hotlists

Hotlists containing this issue:
Top-Starred-Bugs


Sign in to add a comment

Add support for element() in <image>

Reported by golo...@gmail.com, Jan 3 2012

Issue description

Chrome Version       : 16.0.912.63
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) : http://www.w3.org/TR/css3-images/
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: FAIL
  Firefox 4.x: FAIL
     IE 7/8/9: FAIL

What steps will reproduce the problem?
1. Я думаю, что это очень важный шаг.
2. Нужно удалить поддержку в дальнейших версиях хрома (хотя в первых 3 лучше оставить).
3. Это стабильная версия, и она должна быть внесена в поддержку этим браузером.

What is the expected result?


What happens instead?


Please provide any additional information below. Attach a screenshot if
possible.

UserAgentString: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7



 

Comment 1 by tkent@chromium.org, Jan 5 2012

Labels: -Type-Bug -Area-Undefined Type-Feature Area-WebKit WebKit-CSS WebKit-Rendering

Comment 2 by kareng@google.com, Jan 24 2012

mike these look like CSS please unassign urself if they are not.

Comment 3 by kareng@google.com, Jan 24 2012

Owner: mikelawther@chromium.org
Status: Assigned
mike these look like css, please unassign urself if they are not.
Project Member

Comment 5 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit -WebKit-CSS -WebKit-Rendering Cr-Content Cr-Content-CSS Cr-Content-Rendering
Project Member

Comment 6 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 7 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content-Rendering Cr-Blink-Rendering
Project Member

Comment 8 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content-CSS Cr-Blink-CSS
Labels: -OS-Windows OS-All
Owner: ----
Status: Available
Summary: Add support for element() in <image> (was: Please - add CSS -webkit-element() support)
This is defined in CSS Images Level 4 now, http://dev.w3.org/csswg/css-images/
 Issue 122945  has been merged into this issue.
Labels: -Cr-Blink-Rendering Cr-Blink-Layout
Migrate from Cr-Blink-Rendering to Cr-Blink-Layout
Cc: nyerramilli@chromium.org
 Issue 478616  has been merged into this issue.
Labels: -Cr-Blink-Layout Cr-Blink-Paint

Comment 14 by acte...@gmail.com, May 22 2015

I'm is golod95@gmail.com, but in new email. 
 Issue 492959  has been merged into this issue.
 Issue 108270  has been merged into this issue.
Labels: -Cr-Blink

Comment 18 by acte...@gmail.com, Dec 13 2015

I tried make support, but me - really hard task give browser work. 
Labels: -Pri-2 Pri-3
Owner: shans@chromium.org
FYI the steps in Russian are not actually steps, just arguments for why we should implement this :)

Changing this to P-3 since it's a feature, and leaving it open for whoever wants to own this.

shans - do you think this is something we should look at implementing, or is this made obsolete by custom paint?
Owner: ----
Parts of this are made obsolete, but from memory not all of it. We could look at incorporating the rest into custom paint too, but I don't know whether that's a good idea or not. Let's leave the bug open for now.
Labels: Update-Quarterly
Using the paint api to do what element() is most important for as far as I'm aware, which is putting an animated canvas as a background image with good performance, is like shooting small birds with huge flak cannons.

To make matters worse, https://groups.google.com/forum/#!topic/mozilla.dev.platform/uI5bHZil2KU suggests implementing the paint api with 3d acceleration will be hard to do, and -moz-element (the element() implementation) is already present and works perfectly fine 3d accelerated. Unless you are certain this is not the case, it seems element() is worth it for an alternate superior performance path alone.

Therefore, I suggest you reconsider to put in element() anyway, both because it's much simpler to use and understand and because for the potential speed for the canvas use case.

Also just to remind you, since you decided to pull out -webkit-canvas WITHOUT landing any proper replacement which in my opinion was a rather misguided idea (the painful DOM hackery workaround suggested for  people who really need a canvas in the background is a bad joke considering this can be done with -moz-element or -webkit-canvas in a CSS one liner with a simple hidden canvas in the DOM) this has suddenly become an urgent matter. This also suggests adding element() first might be better, since I suppose it's easier and quicker to do - and your browser needs something now, since you just removed the only non-pita way of doing this sanely with -webkit-canvas.

Comment 23 by acte...@gmail.com, Feb 19 2017

I'm owner of this bug... But nobody not believe. I removed this account ( golo...@gmail.com many years ago). I suggest another issue by acterhd@gmail.com owner. 
I agree that element() would be simple and beautiful solution--. I was happy using -webkit-canvas() to make use of a video consists of multiple videos to layout separate videos in client side, to dynamically control the video layout, minimizing the bandwidth consumption. I know -webkit-canvas() itself wasn't hardware accelerated, but it was easy and practical solution since it was also supported in Safari. For Mozilla we needed a tiny change to make a polypill by using -moz-element(). Easiness of the multiple platform support/alignment would also be a big matter for us waiting for this feature.

Comment 25 by suzyh@chromium.org, Mar 30 2017

Labels: Objective
Labels: -Update-Quarterly

Sign in to add a comment