Is it better to start my own Feature Request thread or add on to this one?
First, I +1 all the notes above. This would be a great feature and seems pretty doable today. Here are a few of my own:
CSS fills (i.e. a code-free way to point to a small image in the Asset Library and make it tile on the x, the y, or both to fit a shape.
Justify text in the text panel (Resdesign mentioned this in another thread I believe)
Sound support (The ideal UI would be something that allows you to trigger a sound event as easy as you trigger a timeline "play" event. You just point to the sound asset in the library.
Better Vector art support (i.e. scale SVG today, with an eye toward animating the stroke and fill and maybe someday animating the vectors themselves. Hey, I can dream, right.)
Speaking of SVGs. If I edit the scale of an SVG, why does it grind the animation to a halt?
"Css fills": Background-images aren't tweenable. I'm not sure how prominent a place they deserve in the UI.
"Sound support". HTML5 audio has massive latency problems. The solution is the Web Audio API, but it currently has zero support in IE and firefox: http://caniuse.com/audio-api
"SVG tweening": Yes, this the dream, and hopefully the future.
>> "Css fills": Background-images aren't tweenable. I'm not sure how prominent a place they deserve in the UI.
Well, you cannot tween the typeface either. Nor a shape's border style. There are some things that are so useful that they need to be in the panel. I would argue that this is one of them. Maybe the ideal would be an extra switch next to the color selector that opens up a gradient designer and/or offers a library selector to choose a tiling background.
I realize adding gradients fills and css backgrounds are available through writing custom CSS. This would help people that don't want to touch code. It would, quite frankly, make life easier even for people that can hand-write the css for a gradient or a tiling image.
- I totally agree with good sound support in the future though of course I wish browser support was better but since mp3 is copyrighted then we have to use ogg files for the browser that are open source or do not have the fund to add mp3 like Firefox for example. I guess we should be able to add sound from the left panel with a possibility to check for every sound file support.
- Also I second the idea of having as many additional shadows as we want - like having an ADD a SHADOW button that would open a new line for shadows.
For example a glow is better made with 6 or more shadows.
Another text feature: line-height for css code:
and gradient for css - I suppose different browser support could be added in the panel too.
sym.$("yearLine").css("background-image", "-moz-linear-gradient(left,#0a5696 ,#00bff3, #ffffff)");
Browser support: would add the code according to browser chosen by user: Most people would choose all but in my case we support only Firefox - so no unecessary code needed.
Below is a possible layout: (text-justify and gradients added)
Great suggestions in here! One thing I think might have gotten missed is you can adjust border opacity in the colour popup using the alpha value in the colour picker.
Now it's worth noting that due to the nature of CSS, the border transparency will adjust the alpha overtop of the existing element colour. To achieve an external border we have to use the CSS outline property, however this presents some new challenges as the border doesn't get calculated with the element size and stuff like positioning gets all out of whack.
That being said expanding our border properties is something on our backlog to tackle for the future - there's a lot of awesome stuff we can do here to give designers an extra edge (hah that works on so many levels) with their designs.
1) I think any browser support options belong in an export panel, not in the main UI. Screen space is precious. The UI should be things that are consulted and monitored, and adjusted regularly while refining and tweaking an animation. I honestly don't think these meet that test.
2) With mass unprefixing and standardization that's going on right now with Firefox 16 and IE10, the code base required for interoperability is getting smaller and smaller. I predict the code savings would actually be negligible
3) Why would you build an HTML5 app targeting only Firefox in this day and age? If you're working in such a controlled and precisely targeted environment, there are honestly way better tools out there.
4) I like the idea of a gradient panel. But under the hood, Edge gradients should be be animatable SVG, not CSS. CSS gradients are just background-images, and aren't tweenable. See:
Firefox: This is not my choice but the curriculum system programmer's! I have no say in this matter. Since we use images to load our computer software, we have the control of what browser is used. But eventually we will have to expand to other browsers I am sure. So, generally, I build my Edge pieces to cover the maiin browsers.
I do use gradient outside of CSS too but it is sometimes useful
You're right about selecting opacity in the color picker. That's probably cleaner. But it doesn't bother me in the slightest that a border with an alpha is rendered over the background-color. That's CSS. (Just use a bg color of "none" if that's what you need.)
1) Please don't use CSS "outline" for any heavy lifting in Edge. The interoperability problems are currently massive. For one thing, Firefox draws outlines outside of any box-shadow, contrary to the spec. This bug has festered for three years now, and shows no sign of ever being fixed:
The other big limitation is that outline edges are always square, and can't be rounded. To create what you're calling an "external" border just use a box shadow with no blur. This is a standard practice, and renders well. Whatever you do, please don't make a panel called "borders" that actually creates box-shadows. The answer is education and evangelism, not mislabelling things.
2) Borders don't change the external dimensions of an element if you use border-box globally. Positioning doesn't get the least bit "out of whack." There shouldn't be any trepidation there. This is probably how Edge should work across the board, for all elements, especially if the math of box-sizing is getting you and your engineering team down For folks who aren't hip to this yet, see this fiddle:
and this explanation of the property:
Borders and Box-shadow panels need to be in the "frontlog", not the backlog.
Add "corners" for images too.
Now possible with CSS.
Example for image named "thumb":
+1 for rounded image corners.