Replies: 10 comments 12 replies
-
Just curious, what about custom elements? Do those count as HTML in this context or would that fall under "adding JS to the equation" (yes, it's literally adding JS, but roll with me). |
Beta Was this translation helpful? Give feedback.
-
|
The key concept is you'd be creating just a string of HTML, and custom elements are HTML, so yeah, custom elements would work. But they would have to be available in the context that the theme is being used in, they don't just come along with the theme. That would be obvious for media chrome elements. Others probably look like theme dependencies. |
Beta Was this translation helpful? Give feedback.
-
|
I think that we should lean into the web component angle more and define themes as web components that wrap media-chrome+HTML+CSS. If themes are just HTML/CSS it makes sharing them not as easy, but if they're web components, folks can grab them and use them more easily. This does blur the line a bit between Player and Theme, but Themes probably shouldn't be including much extra functionality that a player could/would. Themes should also then provide enough hooks/slots/parts/etc so that a Player using the theme has access to everything it needs for the added functionality it will add. |
Beta Was this translation helpful? Give feedback.
-
Can you say more about what you mean by that?
Where could we draw a clear line then?
This is where I get a little concerned about the future complexity of themes. I'm not sure what the exact needs will be, but if players ultimately want access to more inside the theme, like the media-controller, I feel like it'd be better if players were just cloning theme HTML into their doms, rather than making the Theme element the middle person, and expecting more of themes than just defining the layout. I do still like using a theme custom element in a simple, non-player situation for easy theming, but that could just be a generic |
Beta Was this translation helpful? Give feedback.
-
|
CSS is decently easy to share, but HTML isn't really. Since, with CSS you can @cjpillsbury is writing a longer answer with more details that should cover the functionality aspect of things. |
Beta Was this translation helpful? Give feedback.
-
|
I like this concept but more as a Media Chrome build tool that can be used to do rapid theme development but with more constraints, good defaults. I had worked on something in these lines a while back, goal was to separate each asset html, css, svg in its own container. https://github.com/luwes/media-theme-jump-start I'm a little worried if this would be the only way to build themes, loses a lot of flexibility that JS provides. |
Beta Was this translation helpful? Give feedback.
-
What if javascript is allowed, but themes are still defined as html (an html doc partial, with a slot for the media)? Include any js and css you want in that html. Does that relieve some of the concern? The media-theme-jump-start is awesome, and also a little intimidating. At least coming from the world of video.js CSS skins.
I do think media-container ultimately has to provide an opinionated solve for responsiveness, but I don't know that it has to be the only way. |
Beta Was this translation helpful? Give feedback.
-
Hey I was hoping to draft a document broadly discussing these topics. The majority of these fall into allowing a theme to be in some sense "configurable"/"dynamic", as opposed to a static, "render once in a very specific way" DOM structure (including attributes). Likewise, if these are missing from a given theme/from a constrained view of "themes," the majority of what will result can be described as "reduced functionality and configurability," and not catastrophic errors. I'll be providing separate replies for the different categories as I draft them so folks can respond to each as a thread. |
Beta Was this translation helpful? Give feedback.
-
|
My S1 is it would be unfortunate if relying on themes resulted in developers/implementors having to make tradeoffs on functionality they get from using Media Chrome directly vs. functionality they get from using a "theme". Unless we come up with alternative solutions (which can/arguably should include "beefing up"
|
Beta Was this translation helpful? Give feedback.
-
Providing well defined configuration attributes to Media Chrome elementsThings like Note that nothing will "catastrophically break" if these simply aren't made available in a "basic theme," but that does mean folks will loose functionality if they decide to adopt a basic theme. While that will always be true to some extent, since these are well-defined on "official" Media Chrome elements, this is something we could architect for. |
Beta Was this translation helpful? Give feedback.
-
|
Some of these could be provided on the MediaTheme class. |
Beta Was this translation helpful? Give feedback.
-
|
correct/agree, though something would have to be responsible for "detecting" elements in the shadow DOM template and applying the attributes accordingly (by convention) if we want a particular theme to preclude javascript/dynamic updates to their template. So there are two parts:
|
Beta Was this translation helpful? Give feedback.
-
Providing attributes that give context/content to rendering the UISome of these are simple, such as having a Here, there may be some UI errors or unanticipated/"weird" state if users e.g. interact with the UI before a src is set (there's a related conversation in media chrome here #288). Under most use cases, however, this is similar to "Providing well defined configuration attributes" in that nothing will "catastrophically break" but some features will be unavailable. |
Beta Was this translation helpful? Give feedback.
-
Providing custom elements via slots to externalize componentsCurrently we rely on two custom slots in our theme: Both were slotted because both the state and the components weren't "well-defined" in Media Chrome in a way that aligned with our timeline. Note that even if these do eventually get integrated into Media Chrome's state and component architecture, we've previously acknowledged the possibility that some things that make sense for Mux Player may never get formally adopted into Media Chrome, and that it's even more plausible that there will at least be a delay between adoption to Media Chrome and need in Mux Player. Here again, nothing will catastrophically break if these are unavailable, but that does mean users and implementors would loose these features when using a "basic" theme that precludes javascript. (Though hypothetically we could refactor the error dialog to not be part of the theme at all, since it's an "overlay". |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
++ I like simplicity, especially as a starting point
I think this should be true no matter what. The simplest version of a theme should be exactly what you're proposing here demuxed 2022 theme. I think right now, the big blocker to even having a simple theme be pure HTML + CSS is the lack of responsiveness primitives. Even the simplest theme must be able to be responsive. If we have that, then the simplest themes can be pure HLML + CSS, thus unlocking the ability for any designer who knows HTML + CSS to build a theme without touching javascript
These 2 benefits don't feel super strong to me, loading a custom element or copy/pasting custom element code is just as easy as copy/pasting HTML and CSS I think where this breaks down, and where javascript is required is for any theme to do anything slightly interesting, beyond the basics. ExampleI am creating a theme that has a "Buy Now" button in the top right of the player, I might define an interface like <media-theme-shopping buy-now-target="/checkout-page">
<video slot="media"></video>
</media-theme-shopping>In order to do that, I would necessarily need some JS that listens to the I would think that theme authors can define attributes like this, how would it be done with JS or without setting up an |
Beta Was this translation helpful? Give feedback.
-
|
I appreciate all the feedback here, and I've been ruminating on all the conversations. One detail that's come up a few times is remixing, and I think it's worth calling out "ease of remixing" as a clear goal, that's on the other end of the spectrum from "advanced/dynamic player". What I mean by remixing is the ability to take an existing theme and modify it completely, whether to be shared as a new theme or just customized within the user's project. I wouldn't be surprised if this is an incredibly common use case, compared with using the pre-baked custom element version of a theme, which you can only customize by setting variables. On our future themes site, we don't just want a handful of themes, we want thousands of them, so we should pay close attention to the friction points in creating a theme. From that angle, I'm wondering if we require advanced/dynamic themes to still expose a static template version of itself for at least the purpose of remixing. e.g. for Mux Player this look like exposing the Large On-demand version of the HTML as the static template. This probably deserves a bigger, clearer writeup, but I'm interested in any initial thoughts on that. |
Beta Was this translation helpful? Give feedback.
-
|
I like that idea a lot but not sure how it would work. So simplified conclusion:
For the designer themes overcoming that they need to copy / paste the whole theme is the hard part CSS is easily overridden like videojs but HTML structure is more difficult. slots are the most powerful concept here I think. <media-default-theme>
<svg slot="play-icon" path="...." />
<div slot="extra-small-bottom-controls">
<media-play-button></media-play-button>
<my-buy-button></my-buy-button>
</div>
<div slot="large-top-right">
...
</div>
</media-default-theme>I guess stream type etc would also have to be included somehow. we should probably do a spike on a "default" responsive and stream type aware Media Chrome theme and try not to force any JS on the end user |
Beta Was this translation helpful? Give feedback.
-
Yeah, I think we're on the same page, but after solving responsiveness and stream type at the media controller level, I would expect a lot if not the majority of themes on the themes site to be in the realm of designer. Maybe a better way to frame it is: ThemeA web component ( Theme templateA template string or template element, which includes HTML and CSS, can include <!-- Create the theme template -->
<template id="myFancyTheme">
<media-controller>
<slot name="media" slot="media"></slot>
<media-control-bar>
<media-title>{{ myVideoTitle }}</media-title>
<slot name="myCustomControl"></slot>
</media-control-bar>
</media-controller>
</template>
<!-- Load the theme template -->
<media-theme-template-loader myVideoTitle="Element attributes translate to template parts!">
<video slot="media" src=""></video>
<media-play-button slot="myCustomControl"></media-play-button>
</media-theme-template-loader>
I'm not totally following what you mean here. Or at least, I've always felt like HTML was easier than CSS, which I think you're saying the opposite, right? |
Beta Was this translation helpful? Give feedback.
-
|
@heff from our out of band conversation, I think it is a good idea to at least try to have have any "official," "dynamic/templated" theme be able to produce a static representation of what it would/should look like by default/on initial load. I can think of places where this breaks down/puts more burden/"handcuffs" some use cases (e.g. where attribute values are tied to info coming from the slotted media element), but it's a good target to aim for (not sure if it's "blue skies" vs realistic, but that shouldn't matter here). |
Beta Was this translation helpful? Give feedback.
-
I guess I wanted to say here that CSS is easily overridden, because of CSS specificity I can override rules and chance styles. |
Beta Was this translation helpful? Give feedback.
-
|
With the work @luwes has been doing on themes, I'm gonna summarize the current proposal as clearly as I can to invite push back. Themes are <template id="my-fancy-theme">
<style>...</style>
<media-controller>
<slot name="media" slot="media"></slot>
<media-text-display>{{ title }}</media-text-display>
...
</media-controller>
</template>Themes may be packaged as a custom element ( What we're explicitly saying that is different from before is that a theme is not inherently a custom element, it is a We do still have more to figure out, but we're feeling confident in this direction.
We also have things we need to build into media chrome to support common player features without custom code, like seek-to-live. Also, we acknowledge that themes won't be able to solve everything. We want to ultimately make that a small set of things, but for some advanced features you may have to use media chrome elements directly. With themes as |
Beta Was this translation helpful? Give feedback.
-
Prior context: Theme Architecture PR.
There's a handful of threads on themes happening so I've been thinking about it and want to propose a potentially controversial change to the existing themes concept, and surface any clear issues with the direction.
A Skin is CSS.
A Theme is HTML + CSS
Adding JS to the equation is the realm of the Player.
The original theme examples are basically that, with the added wrapper of a custom element to make embedding and registering easier.
With the mux player theme we then expanded on this (using javascript and theme element attributes) to support things like:
This proposal ultimately needs to solve for those needs to be complete. I don't have immediate solutions but I have thoughts and I'm interested in others' ideas.
In general I'm drawn towards the simplicity of the concept, but some rough benefits I see with this approach:
Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions