Definitely an interesting idea. I think we would tone it down and simplify for FWT - but could be quite useful.
DanielFathSun 25 Mar 2012
Interesting idea reminds me of Ted Nelson's idea about three separate levels:
* A content layer to facilitate editing, content linking, and
transclusion management.
* A structure layer, declarable separately.
Users should be able to specify entities,
connectionsand co-presence logic, defined independently
of appearance or size or contents; as well as
overlay correspondence, links, transclusions,
and "hoses" for movable content.
* A special-effects-and-primping layer should
allow the declaration of ever-so-many fonts, format
blocks, fanfares, and whizbangs, and their assignment
to what's in the content and structure layers.
For Fantom I see this better suited as some kind of FanDom web server or something. As for syntaxI'd prefer:
I think the real value here is "selection" - via some form of classes and/or ids. Today you generally have to keep fields pointing to all the widgets you plan to interact with. So I see alot of value in being able to query into a widget tree.
Getting into all the styling aspects is a bit thorny - and would be difficult to make cross platform I think. The approach I used in webfwt is to extend certain widgets and expose overriding styling and/or adding CSS directly - since its designed explicitly to only run in web browsers.
That design worked really well - and we were able to use alot of cools stuff like box-shadow, border-radius, and CSS transitions, since we didn't need to worry about making it work cross-platform.
go4 Sun 25 Mar 2012
If Fwt can work like HTML+CSS+JS that will be interesting:
andy Sun 25 Mar 2012
Definitely an interesting idea. I think we would tone it down and simplify for FWT - but could be quite useful.
DanielFath Sun 25 Mar 2012
Interesting idea reminds me of Ted Nelson's idea about three separate levels:
For Fantom I see this better suited as some kind of FanDom web server or something. As for syntaxI'd prefer:
andy Sun 25 Mar 2012
I think the real value here is "selection" - via some form of classes and/or ids. Today you generally have to keep fields pointing to all the widgets you plan to interact with. So I see alot of value in being able to query into a widget tree.
Getting into all the styling aspects is a bit thorny - and would be difficult to make cross platform I think. The approach I used in
webfwt
is to extend certain widgets and expose overriding styling and/or adding CSS directly - since its designed explicitly to only run in web browsers.That design worked really well - and we were able to use alot of cools stuff like
box-shadow
,border-radius
, and CSS transitions, since we didn't need to worry about making it work cross-platform.