flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <teotigraphix...@gmail.com>
Subject [FlexJS] SVG UI components (was FlexJS event names)
Date Tue, 19 May 2015 18:29:36 GMT
Ironically Om, this was my next post! SVG and what are we doing to use it.

Maybe through all my bable of the last thread some might see where I am
coming from, I am really trying to figure out, what are we building on.

Now SVG I understand, Canvas I understand.

Om, what are the pluses and minuses of each paradigm? I was just reading
about this today, canvas doesn't have event handlers, svg does.

FXG -> SVG, is there currently a parser/renderer for this? How were you
planning on doing this.

Is this something we could write that would pretty much cross compile to js?

Tell me your ideas, I am very interested in this part.



Mike


> See this is my problem, Randori was a straight cross compile with shims
and
> worked awesome. So all my questions to you are like me "unlearning" what I
> spent 6+ months working on in that project.
>
> The compiler's emitter just puked out js and we locked in SWCs in the apps
> that used js API surfaces.
>
> Although, the one thing as you know was Mike disagreed with FlexJS's view
> in ActionScript because he said HTML/CSS designers should just do what
they
> do and design in HTML/CSS.
>

I disagree fundamentally with this idea.  For one, HTML/CSS is a terrible
terrible paradigm.  No designer is happy with the way things work today.  I
would rather provide a better way of doing the visuals via MXML+FXG (like
we do in Flex's spark skins) and cross compile them over to JS + SVG +
Canvas as needed.

Even the HTML/JS world is waking up to this idea.  This presentation [1]
does a great job of explaining why SVG is better than CSS for interfaces
building.  FlexJS is in a great position to provide this out of the box to
developers.

Thanks,
Om

[1] http://slides.com/sarasoueidan/building-better-interfaces-with-svg#/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message