webkit-resource: referring to resources in User Agent stylesheet
Hello, SUMMARY: we would like to introduce a "webkit-resource" URL scheme for CSS, which would refer to images baked into WebKit. BACKGROUND: in order to style media controls today, we rely on the ControlPart enum (http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit...), which is exposed as the -webkit-appearance CSS attribute. For example: video::-webkit-media-controls-play-button { -webkit-appearance: media-play-button; } In addition, the state of the button is further adjusted by looking at the runtime state or media characteristics of the element (is the user currently hovering or clicking on the element? is it playing? is it streaming? has an error occurred?). This happens at the port layer, in RenderTheme implementation. With impending introduction of media element pseudo-classes and the patch in bug 58342 landing, we will be able to sense these extra states at the CSS level: video:playing::-webkit-media-controls-play-button:hover { -webkit-appearance: media-play-button-playing-hover; } This would result in a lot less of mindless style-flipping RenderTheme/MediaControlElement code and provide more flexibility for each port to design their pretty things. However, sticking with existing -webkit-appearance strategy will result in ControlPart enum exploding as combinatorial math suggests. Which is a ... PROBLEM: We need a way to somehow in CSS associate an element state with a relatively arbitrary key to avoid ControlPart from becoming the tallest enum ever. SOLUTION: Looking at the current media controls implementations, most of the -webkit-appearance states are kind of like background images, each reflecting appearance of an element at a particular state. Thus, it seems we should be able to solve this by just using CSS backgrounds: video:playing::-webkit-media-controls-play-button:hover { background: url(/media-controls/play-button-hover.png); } That is how the authors would style the media controls. However, at the UA level, we shouldn't probably be loading resources from random sites. Instead, we need a way to bake these images into the WebKit runtime, and then a way to refer to them from the stylesheet. This is where a vendor-specific URL scheme comes in: video:playing::-webkit-media-controls-play-button:hover { background: url(webkit-resource:/media-controls/play-button-hover.png); } A quick poll of smart people (abarth and smfr) seems to indicate it's not a completely horrid idea. WDYT? Thoughts? Comments? :DG<
On Apr 26, 2011, at 1:18 PM, Dimitri Glazkov wrote:
SOLUTION: Looking at the current media controls implementations, most of the -webkit-appearance states are kind of like background images, each reflecting appearance of an element at a particular state. Thus, it seems we should be able to solve this by just using CSS backgrounds:
video:playing::-webkit-media-controls-play-button:hover { background: url(/media-controls/play-button-hover.png); }
That is how the authors would style the media controls. However, at the UA level, we shouldn't probably be loading resources from random sites. Instead, we need a way to bake these images into the WebKit runtime, and then a way to refer to them from the stylesheet.
This is where a vendor-specific URL scheme comes in:
video:playing::-webkit-media-controls-play-button:hover { background: url(webkit-resource:/media-controls/play-button-hover.png); }
A quick poll of smart people (abarth and smfr) seems to indicate it's not a completely horrid idea.
WDYT? Thoughts? Comments?
FWIW, WebKit/mac generates these images programmatically, so there's not really a URL for "play button hover state" which can be targeted. That said, if the URL scheme could be overloaded to handle generated content, I guess this could still work. WebKit/mac could either parse the URL path and special case "media-controls/play-button-hover.png", or define our own URL scheme, e.g. "background: url(webkit-generated:media-play-button-playing-hover);" But then we're just back to something functionally identical to -webkit-appearance. I guess what I'm getting at is, if support for webkit-resource: is added, great. However, at least one port will still need the old behavior. -Jer
On Tue, Apr 26, 2011 at 1:27 PM, Jer Noble <jer.noble@apple.com> wrote:
On Apr 26, 2011, at 1:18 PM, Dimitri Glazkov wrote:
SOLUTION: Looking at the current media controls implementations, most of the -webkit-appearance states are kind of like background images, each reflecting appearance of an element at a particular state. Thus, it seems we should be able to solve this by just using CSS backgrounds:
video:playing::-webkit-media-controls-play-button:hover { background: url(/media-controls/play-button-hover.png); }
That is how the authors would style the media controls. However, at the UA level, we shouldn't probably be loading resources from random sites. Instead, we need a way to bake these images into the WebKit runtime, and then a way to refer to them from the stylesheet.
This is where a vendor-specific URL scheme comes in:
video:playing::-webkit-media-controls-play-button:hover { background: url(webkit-resource:/media-controls/play-button-hover.png); }
A quick poll of smart people (abarth and smfr) seems to indicate it's not a completely horrid idea.
WDYT? Thoughts? Comments?
FWIW, WebKit/mac generates these images programmatically, so there's not really a URL for "play button hover state" which can be targeted. That said, if the URL scheme could be overloaded to handle generated content, I guess this could still work. WebKit/mac could either parse the URL path and special case "media-controls/play-button-hover.png", or define our own URL scheme, e.g. "background: url(webkit-generated:media-play-button-playing-hover);" But then we're just back to something functionally identical to -webkit-appearance. I guess what I'm getting at is, if support for webkit-resource: is added, great. However, at least one port will still need the old behavior.
Yes! The -webkit-appearance must stay. This is purely an additive thing.
-Jer _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Apr 26, 2011, at 1:45 PM, Dimitri Glazkov wrote:
On Tue, Apr 26, 2011 at 1:27 PM, Jer Noble <jer.noble@apple.com> wrote:
FWIW, WebKit/mac generates these images programmatically, so there's not really a URL for "play button hover state" which can be targeted. That said, if the URL scheme could be overloaded to handle generated content, I guess this could still work. WebKit/mac could either parse the URL path and special case "media-controls/play-button-hover.png", or define our own URL scheme, e.g. "background: url(webkit-generated:media-play-button-playing-hover);" But then we're just back to something functionally identical to -webkit-appearance. I guess what I'm getting at is, if support for webkit-resource: is added, great. However, at least one port will still need the old behavior.
Yes! The -webkit-appearance must stay. This is purely an additive thing.
Would we end up with different stylesheets for different ports, then? (Or is media control styling already different between ports?) Regards, Maciej
On Tue, Apr 26, 2011 at 7:50 PM, Maciej Stachowiak <mjs@apple.com> wrote:
On Apr 26, 2011, at 1:45 PM, Dimitri Glazkov wrote:
On Tue, Apr 26, 2011 at 1:27 PM, Jer Noble <jer.noble@apple.com> wrote:
FWIW, WebKit/mac generates these images programmatically, so there's not really a URL for "play button hover state" which can be targeted. That said, if the URL scheme could be overloaded to handle generated content, I guess this could still work. WebKit/mac could either parse the URL path and special case "media-controls/play-button-hover.png", or define our own URL scheme, e.g. "background: url(webkit-generated:media-play-button-playing-hover);" But then we're just back to something functionally identical to -webkit-appearance. I guess what I'm getting at is, if support for webkit-resource: is added, great. However, at least one port will still need the old behavior.
Yes! The -webkit-appearance must stay. This is purely an additive thing.
Would we end up with different stylesheets for different ports, then? (Or is media control styling already different between ports?)
Yeah, it's already different. :DG<
Regards, Maciej
Would we want this to be web facing? Or should we limit it to inside the built-in stylesheets? -Sam On Apr 26, 2011, at 1:18 PM, Dimitri Glazkov wrote:
Hello,
SUMMARY: we would like to introduce a "webkit-resource" URL scheme for CSS, which would refer to images baked into WebKit.
BACKGROUND: in order to style media controls today, we rely on the ControlPart enum (http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit...), which is exposed as the -webkit-appearance CSS attribute. For example:
video::-webkit-media-controls-play-button { -webkit-appearance: media-play-button; }
In addition, the state of the button is further adjusted by looking at the runtime state or media characteristics of the element (is the user currently hovering or clicking on the element? is it playing? is it streaming? has an error occurred?). This happens at the port layer, in RenderTheme implementation.
With impending introduction of media element pseudo-classes and the patch in bug 58342 landing, we will be able to sense these extra states at the CSS level:
video:playing::-webkit-media-controls-play-button:hover { -webkit-appearance: media-play-button-playing-hover; }
This would result in a lot less of mindless style-flipping RenderTheme/MediaControlElement code and provide more flexibility for each port to design their pretty things.
However, sticking with existing -webkit-appearance strategy will result in ControlPart enum exploding as combinatorial math suggests. Which is a ...
PROBLEM: We need a way to somehow in CSS associate an element state with a relatively arbitrary key to avoid ControlPart from becoming the tallest enum ever.
SOLUTION: Looking at the current media controls implementations, most of the -webkit-appearance states are kind of like background images, each reflecting appearance of an element at a particular state. Thus, it seems we should be able to solve this by just using CSS backgrounds:
video:playing::-webkit-media-controls-play-button:hover { background: url(/media-controls/play-button-hover.png); }
That is how the authors would style the media controls. However, at the UA level, we shouldn't probably be loading resources from random sites. Instead, we need a way to bake these images into the WebKit runtime, and then a way to refer to them from the stylesheet.
This is where a vendor-specific URL scheme comes in:
video:playing::-webkit-media-controls-play-button:hover { background: url(webkit-resource:/media-controls/play-button-hover.png); }
A quick poll of smart people (abarth and smfr) seems to indicate it's not a completely horrid idea.
WDYT? Thoughts? Comments?
:DG< _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
It would be extremely easy to limit it to UA sheets only. :DG< On Tue, Apr 26, 2011 at 2:05 PM, Sam Weinig <weinig@apple.com> wrote:
Would we want this to be web facing? Or should we limit it to inside the built-in stylesheets?
-Sam
On Apr 26, 2011, at 1:18 PM, Dimitri Glazkov wrote:
Hello,
SUMMARY: we would like to introduce a "webkit-resource" URL scheme for CSS, which would refer to images baked into WebKit.
BACKGROUND: in order to style media controls today, we rely on the ControlPart enum (http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit...), which is exposed as the -webkit-appearance CSS attribute. For example:
video::-webkit-media-controls-play-button { -webkit-appearance: media-play-button; }
In addition, the state of the button is further adjusted by looking at the runtime state or media characteristics of the element (is the user currently hovering or clicking on the element? is it playing? is it streaming? has an error occurred?). This happens at the port layer, in RenderTheme implementation.
With impending introduction of media element pseudo-classes and the patch in bug 58342 landing, we will be able to sense these extra states at the CSS level:
video:playing::-webkit-media-controls-play-button:hover { -webkit-appearance: media-play-button-playing-hover; }
This would result in a lot less of mindless style-flipping RenderTheme/MediaControlElement code and provide more flexibility for each port to design their pretty things.
However, sticking with existing -webkit-appearance strategy will result in ControlPart enum exploding as combinatorial math suggests. Which is a ...
PROBLEM: We need a way to somehow in CSS associate an element state with a relatively arbitrary key to avoid ControlPart from becoming the tallest enum ever.
SOLUTION: Looking at the current media controls implementations, most of the -webkit-appearance states are kind of like background images, each reflecting appearance of an element at a particular state. Thus, it seems we should be able to solve this by just using CSS backgrounds:
video:playing::-webkit-media-controls-play-button:hover { background: url(/media-controls/play-button-hover.png); }
That is how the authors would style the media controls. However, at the UA level, we shouldn't probably be loading resources from random sites. Instead, we need a way to bake these images into the WebKit runtime, and then a way to refer to them from the stylesheet.
This is where a vendor-specific URL scheme comes in:
video:playing::-webkit-media-controls-play-button:hover { background: url(webkit-resource:/media-controls/play-button-hover.png); }
A quick poll of smart people (abarth and smfr) seems to indicate it's not a completely horrid idea.
WDYT? Thoughts? Comments?
:DG< _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
participants (4)
-
Dimitri Glazkov
-
Jer Noble
-
Maciej Stachowiak
-
Sam Weinig