I understand that you want to use the default HTML elements as building
blocks. I think there are major problems with this approach.
First of all, there are only a small set of default input types UI elements:
button, checkbox, radio and text.
HTML5 adds a few more UI elements:
color, date, datetime, datetime-local, month, week, time, email, number,
range, search, tel, and url.
None of the new HTML5 elements work cross-browser. Most cases, even Chrome
and Firefox don't support it, leave alone IE and Safari.
In essence, we have a very limited set of default HTML elements to start
with. If we want to compose our entire application with these, we will
quickly run into cases where we need more complex base components.
Second, if we want to look around for commonly used patterns, we can
quickly find that default HTML elements are not sufficient to build real
applications. As an example, this is how two of the most popular
JavaScript component libraries build their buttons. All this for nothing
but a button:
*Default Button in Dojo* (Not showing all the CSS styles)
<span class="dijitReset dijitInline dijitButtonNode"
data-dojo-attach-event="ondijitclick:__onClick" role="presentation">
<span style="-moz-user-select: none;" id="progButtonNode" tabindex="0"
class="dijitReset dijitStretch dijitButtonContents"
data-dojo-attach-point="titleNode,focusNode" role="button"
aria-labelledby="progButtonNode_label">
<span class="dijitReset dijitInline dijitIcon dijitNoIcon"
data-dojo-attach-point="iconNode"></span><span class="dijitReset
dijitToggleButtonIconChar">●</span>
<span class="dijitReset dijitInline dijitButtonText"
id="progButtonNode_label" data-dojo-attach-point="containerNode">Click
me!</span>
</span>
</span>
<input value="" class="dijitOffScreen"
data-dojo-attach-event="onclick:_onClick" tabindex="-1" role="presentation"
aria-hidden="true" data-dojo-attach-point="valueNode" type="button">
*Icon Button in jQuery* (Not showing all the CSS styles)
<button class="ui-button ui-widget ui-state-default ui-corner-all
ui-button-text-icon-primary" role="button">
<span class="ui-button-icon-primary ui-icon ui-icon-locked"></span>
<span class="ui-button-text">
Button with icon on the left
</span>
</button>
Now coming to the approach of using SVG to define the skins. I have looked
around and not too many examples of this approach. I believe it is because
of the fact that cross browser SVG support was late to arrive and people
have not experimented with this idea much.
(Continuing inline...)
On Thu, Oct 16, 2014 at 8:59 AM, Alex Harui <aha...@adobe.com> wrote:
> Ah yes, skinning in FlexJS.
>
> The general guidance for doing anything in FlexJS is to first consider
> what is possible/practical/popular on the HTML/JS/CSS side, find the
> patterns, propose encapsulations, then figure out how to implement that in
> AS.
>
> I’ve never promised FlexJS would offer Spark-like skinning because I’m not
> sure it is possible or practical in HTML/JS/CSS. Spark skinning basically
> adds a child display object to any component. I am not convinced you can
> do that to the HTML built-in widgets I think most folks will want to use.
> FlexJS certainly allows for a component set of widgets written to emulate
> the built-in HTML widgets that can have an extra display object child, but
> practically speaking, I want to leverage the built-in widgets so we don’t
> have to invest time now in debugging emulations of them. Also, FlexJS
> hopes to support other component sets that wrap other UI frameworks like
> Jquery and the way to customize the visuals may differ from framework to
> framework.
>
> The “basic” FlexJS framework tries to support MVC in most of the
> components. The view bead isn’t an extra display object, it adds display
> objects (or sub-components) to the host components that can have
> sub-components. Fine tuning of the visuals is controlled via CSS. On the
> HTML/JS/CSS side, the FlexJS Button doesn’t currently have a view bead
> since it just thinly wraps the HTML Button and that’s why fine tuning of
> the visuals is controlled via CSS: I think that’s the only way to alter
> the way the HTML Button looks.
>
Yes, using CSS is the only way to alter a HTML button's look and feel.
Which is why most component libraries compose a button from scratch using
divs and spans (as shown above)
>
> The one scenario that I keep thinking of, but haven’t fully explored, is
> the “closeable tab”. FlashBuilder/Eclipse users see it all the time:
> there are tabs representing the open files in the source editor, and you
> can close a file by hovering over the tab and clicking a close button that
> will appear.
>
> I have not researched how this is done in HTML/JS/CSS, but in Flash, folks
> tried to do this by adding a button to the tab skin, and the tab is
> already a button. I don’t think you can do this to the default HTML
> Button, but I could be wrong, but that’s been a factor in why I don’t
> think we can replicate Spark skinning in every component.
>
Yes, these kind of scenarios are exactly why relying on the simple HTML
button elements won't work for us.
*In jQuery:*
<div class="ui-dialog ui-widget ui-widget-content ui-corner-all ui-front
ui-draggable ui-resizable" style="position: absolute; height: 152px; width:
303px; top: 28px; left: 166px; display: block;" tabindex="-1" role="dialog"
aria-describedby="dialog" aria-labelledby="ui-id-1">
<div class="ui-dialog-titlebar ui-widget-header ui-corner-all
ui-helper-clearfix ui-draggable-handle">
<span id="ui-id-1" class="ui-dialog-title"></span>
<button class="ui-button ui-widget ui-state-default ui-corner-all
ui-button-icon-only ui-dialog-titlebar-close" type="button" role="button"
title="Close"></button>
</div>
<div id="dialog" class="ui-dialog-content ui-widget-content"
style="width: 281px; min-height: 107px; max-height: none; height:
115px;"></div>
</div>
*In Dojo:*
<div id="dijit_Dialog_0" class="dijitDialog dijitDialogFocused
dijitFocused" aria-labelledby="dijit_Dialog_0_title" role="dialog"
style="width: 300px; position: absolute; opacity: 1; left: 199px; top:
163px; z-index: 950;" widgetid="dijit_Dialog_0">
<div class="dijitDialogTitleBar" data-dojo-attach-point="titleBar">
<span id="dijit_Dialog_0_title" class="dijitDialogTitle" level="1"
role="heading" data-dojo-attach-point="titleNode"></span>
<span class="dijitDialogCloseIcon" tabindex="-1" role="button"
title="Cancel" data-dojo-attach-event="ondijitclick: onCancel"
data-dojo-attach-point="closeButtonNode"></span>
</div>
<div class="dijitDialogPaneContent"
data-dojo-attach-point="containerNode"></div>
</div>
>
> So, starting from the HTML/JS/CSS side, what can we do? We can specify
> CSS background-image for lots of things, although IIRC, there are some
> flicker issues with SVG background-image in Buttons. We can specify
> sub-components for components that aren’t based on HTML widgets. And are
> different things possible for a component set that is HTML5-only?
>
The flicker shows up in a specific setup. I was able to overcome this by
doing things differently. Here are a couple of example that I put up a
while ago that shows that it is possible:
http://people.apache.org/~bigosmallm/fxg2svg/buttonskin/flexVhtml5.html
http://people.apache.org/~bigosmallm/fxg2svg/buttonskinjs/embedButtons.html
>
> If you look at FlexJSJX/src/org/apache/flex/html/beads/TitleBarView.mxml
> we can now specify the sub-component in the view in MXML. IIRC, you still
> want to convert FXG to SVG so the AS-side could load FXG and the JS-side
> could load SVG. Or we could just make the AS-side understand SVG and
> convert to Graphics commands on the fly.
>
There are some scenarios where SVG is not good enough for us. For example,
9-slice scaling. SVG does not support this flat out. Whereas, there is a
way to hack 9-slice skinning using SVG and ForeignObjects. But none of the
drawing tools (Illustrator, Flash Pro or Incscape) support this hack.
I plan to interpret the 9-slice attributes (exported from AI, for example)
and draw the svg/foreignobject combinations on the JS side. On the flash
side, 9-slice skinning is supported built in.
Also, loading SVG instead of drawing it using JS brings its own set of
challenges. I feel drawing SVG using JS is a better approach.
>
> But fundamentally, I think we now have the ability to specify just about
> every visual aspect of a FlexJS app as MXML plus some CSS, but I think the
> HTML Button might flicker, and not all MXML will work in all components in
> the JS side unless I’m wrong about the "closeable tab” scenario. Maybe
> that means there should be some other default Button in FlexJS and we
> should give up on the built-in HTML Button or maybe that’s good enough.
>
Yes, IMHO, we should give up on the build-in HTML button. That is good for
simple websites, not as a building block for complex applications. As
evidenced by the design choices of the popular JS UI libraries like jQuery
and Dojo.
> What do other think?
>
>
I would love to hear what others think of this problem.
Thanks,
Om
> -Alex
>
>
>
> On 10/16/14, 2:06 AM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote:
>
> >I have checked in the required changes to support FXG/MXMLG style drawing
> >in FlexJS. I have also updated the chart classes to accommodate for these
> >changes so that they continue to work properly.
> >
> >Next up, figure out how to skin a component in FlexJS!
> >
> >Thoughts, suggestions?
> >
> >Thanks,
> >Om
> >
> >On Wed, Oct 15, 2014 at 8:31 PM, Alex Harui <aha...@adobe.com> wrote:
> >
> >>
> >>
> >> On 10/15/14, 2:53 PM, "OmPrakash Muppirala" <bigosma...@gmail.com>
> >>wrote:
> >>
> >> >
> >> >On the JS side, I now have GraphicShape extend UIBase as well. I added
> >> >the
> >> >same exact code path as in the AS version.
> >> >
> >> >We now have FXG like drawing on both Flash and HTML5/SVG with close to
> >> >100%
> >> >fidelity :-)
> >> Sweet!
> >>
> >> -Alex
> >>
> >>
>
>
