Closed Bug 811823 Opened 12 years ago Closed 4 years ago

Configuration dialog for inserting live samples

Categories

(developer.mozilla.org Graveyard :: Editing, defect, P5)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: sheppy, Unassigned)

References

Details

(Whiteboard: [type:feature])

When you click the live sample button, I'd like a dialog that lets you configure the following things for the new live sample:

* Name of the sample (for the heading and ID)

* Whether or not to have subheadings for the HTML, CSS, and JavaScript code blocks

* Width and height of the iframe (defaulting to something reasonable)
Thanks for pointing this out. A few quick questions...

> * Name of the sample (for the heading and ID)

Should all code samples be preceded by a new heading?

> * Whether or not to have subheadings for the HTML, CSS, and JavaScript code
> blocks

Which demos do you see not needing subheadings for HTML, CSS, and JS?

> * Width and height of the iframe (defaulting to something reasonable)

When do you see yourself needing a non-default iframe size?

Just trying to think of ways to make these options all as seamless as possible -- maybe even automatic if they are always used for similar purposes.
Flags: needinfo?(eshepherd)
(In reply to John Karahalis [:openjck] from comment #1)

> Should all code samples be preceded by a new heading?

Yes, this is required by the code sample system. I mean, it doesn't need to be a heading just for the sample, but since we're inserting a heading, we might as well let the user configure it.

> Which demos do you see not needing subheadings for HTML, CSS, and JS?

Any demo that's only a snippet of HTML, for example, would not need these headings.

> > * Width and height of the iframe (defaulting to something reasonable)
> 
> When do you see yourself needing a non-default iframe size?

Examples:

* A sample that only outputs a single line of content does not need a tall iframe, but might need a wide one.

* A sample that shows an animation may need a very wide and/or very tall iframe to make the demonstration visible.
Flags: needinfo?(eshepherd)
Good stuff.

> Yes, this is required by the code sample system. I mean, it doesn't need to
> be a heading just for the sample, but since we're inserting a heading, we
> might as well let the user configure it.

What about not adding a heading by default, and letting the editor add one manually if they want to. Better? Worse?

> Any demo that's only a snippet of HTML, for example, would not need these
> headings.

Cool. We can look into only showing headings for components that are actually used.

> Examples:
> 
> * A sample that only outputs a single line of content does not need a tall
> iframe, but might need a wide one.
> 
> * A sample that shows an animation may need a very wide and/or very tall
> iframe to make the demonstration visible.

All good points. This might be the same reason jsFiddle allows you to customize the <iframe> size.

I will split this into a couple different features, pending what you think about the first idea.
(In reply to John Karahalis [:openjck] from comment #3)

> What about not adding a heading by default, and letting the editor add one
> manually if they want to. Better? Worse?

Worse; the code inserted by the live sample button has to know what this heading is in order to generate the correct code to inject.

> > Any demo that's only a snippet of HTML, for example, would not need these
> > headings.
> 
> Cool. We can look into only showing headings for components that are
> actually used.

We might ask the user which sections need to be inserted; I dunno.
Priority: -- → P2
Whiteboard: feature request;
Priority: P2 → P3
Whiteboard: feature request; → [type:feature]
Yeah, I'd like to have something here that uses checkboxes to let you specify which sections to add with edit boxes by each for entering their names.
Blocks: 1244004
Priority: P3 → P5
MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.