Open zachberry opened 4 years ago
To support the changes above, the type
attribute would be expanded to accept "none"
as an option, meaning accepted values would be none
, webpage
and media
. When an iframe is newly created in the editor it would default to none
- that allows you to know when to show the first dialog or the second. An iframe of type none
should ignore all other properties (if an author manually writes a document with <IFrame src="website.com" type="none" />
the src property should be ignored and the iframe would be rendered as empty in the Viewer). We'd make a note in the docs that none
typically wouldn't be used when writing XML/JSON.
The new Sizing property I'm thinking should be called sizing
, with these possible values: max-width
, text-width
and fixed
. In order to not break existing documents if sizing
is not set the default should be fixed
, which is current behavior. However, in the UI when creating a new IFrame the default selected choice would be the "Responsive - full width" option (or max-width
).
Current IFrames (retroactively considered to be fixed
) have their widths max out at the same width as the text. I think the best option moving forward is to now max their widths out at the max possible width (aka same width as questions). This is a breaking change that will change the look of existing documents, however this gives more freedom to authors and potentially causes an iframe that used to have to scale down to no longer scale. My thought is that when choosing the "fixed" option the dimensions of the iframe are the most important consideration, and we should bend as much as possible to allow for the size to match as expected. I'm open to feedback on this however.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep our backlog under control, but we thank you for your contributions.
What we have now in the editor to edit/set iframes was a first step so some of these aren't surprises. That said, the biggest pain for authors adding in iframes is:
Suggesting a revamp of the dialog to solve these problems:
Editing a brand new iframe:
Here we let you paste the iframe embed code from a site, and we'll auto extract all the relevant information - really just "src", "width" and "height". There's also an assumption we'll make here - if you paste in
Here we go ahead and try to embed what you pasted just so you can confirm it's working. If they click the "No" link here it could expand to explain that some pages may restrict their content inside an iframe, or, to make sure if you're trying to embed media to use the iframe code and not the regular url
If you click Yes you'd get to this step:
Here if you click 'Change' it would take you back to the previous page. We'd also go ahead and pre-select Content type for you, based on the assumption I mentioned from earlier.
Assuming that 'Video or other media' is selected, the rest of the dialog is a smaller subset of options. Sizing would define the dimensions of the iframe. The first choice - full width - sets the iframe to the maximum width (same width as questions, which extend past the text). The second choice is similar, it just maxes out at the same width as the text. Finally the last option uses the exact width.
IF the iframe that they copied had width and height values then we can determine the ratio of the iframe - typically for video that will be around 16:9. If you pick the first two responsive options we basically set the width to 100% and use the ratio to determine the height (the iframe node already does this stuff) - but then we don't really need to show you the Width and Height inputs since they are just needed for the ratio. However the 'Edit dimensions' link would let you change those values.
If you picked the Fixed size option you'd be shown the width and height inputs.
If you paste in
Next option - Loading - would replace "autoload". Using a select box instead of the toggle just so that we can explain the different choices, and in the example you can see a warning about why the auto option might be negative. Additionally, we could add in a lazy-load option, if we use IntersectionObservers to determine when the iframe is on the screen.
IF you pick one of the auto-load options you don't need to set the title, so when selecting one of those options we'd hide the title input.
FINALLY, you can click "Show all options" which would give you every option that we're hiding (such as which controls to display, etc). I don't have that UI mocked up here.
IF you paste in an YouTube link we'd notify you that we have a special display for YouTube video and ask if you want to convert this to use the YouTube chunk instead. That UI isn't mocked up (This could be moved to a separate issue)
Second, if you paste in a URL (not