[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] CSS namespaces
|
Hi,
Angelo, Happy BEIJING Days:)
If just myself, I hope eclips CSS not employ W3C CSS, make a eclipse CSS.
:-) BUT eclipse not my eclipse:-)
I sudden recall osgi meta file, another CSS-like. seems make a new CSS
not so hard.
But it's not the key. IMO the key is that, the CSS realy fit SWT.
OKay, we talk about not only SWT, and HTML. I consider 2 points:
Browser application self.
And HTML with CSS.
1, IE, FF, ... these browser application realy fit our future applications?
The answer is sure. RCP, RIA,..., even ajax self, both said, we need
new APPLICATION. of cause, not only application self, protocol is a
key problem too.
2, CSS, not consider html, we can just focus one point, CSS test.
some passed, some not passed. and CSS extensions. IMO, these case tell
use CSS self is a problem.
Now, CSS selector is one of my most hate thing. 2nd, syntax. In most
simple case, CSS syntax like a struct, but the struct attached many
strange designs. That's why I call it not a man, not a ghost. And IMO,
the point veeerry like C++, but java not, so java win, isn't? :-)
Now Web application hot, so ajax hot, and RCP style apps re-hot.
XUL or UIL..., has years, but not hot to top. many reasons, XML maybe
one of these.
JavaFX, AIR, Ms, XForms, all target the target.
HAS options, is good thing, but two many options, MUST not good thing,
which just says, There is no good thing.
So why not eclipse make a good thing, just like make eclipse self? :-)
Regards,
Qinxian
2008/8/9 Angelo zerr <angelo.zerr@xxxxxxxxx>:
> Hi,
>
> I would like just say that w3c provides sac.jar whch contains SAC Parser
> interface.
> Batik, Flute...has implemented this SAC Parser interface. I think it will be
> good
> (as I have done into my TK-UI CSS Engine) to use SAC interface and not
> implementation and have SAC parser factory
> as TK-UI SAC parser factory interface ISACParserFactory.
>
> So Eclipse CSS engine will able to used any one SAC Parser implementation.
>
> Regards Angelo
>
> 2008/8/9 向雅 <fyaoxy@xxxxxxxxx>
>>
>> Thank you for previous hint about my wrong thread. I miss the thank in
>> my last comment.:)
>> Thank you.
>> In my last comment, I said, maybe not only parser. Until now, I still
>> wanna say: maybe not only the parser.
>> From work time watching, You still at work time:) I enjoying 2008
>> BEIJING:) DuLi,
>> previous champion, lost the GOLD in the first match, I feel a bit
>> regret. Our reporter already give her some comfort when gather news,
>> But duli seems feel bad, and give herself some pretext, which I
>> regretted. I known about, indeed, Duli cannot make herself calm at
>> some case, such as audience's speaking. Win or Lost, from nature, NOT
>> so important, The key is participating. For me, who should believe
>> himself. Enjoy 2008 BEIJING.
>> Years ago, JSON out, give me some hint. We talked about quote symbols.
>> I hope remove no-use quotes in text. because the full world people
>> both type the key " at keyboard, that is a BIG huge waste for human
>> time.:)
>> Last year, Another project, from AU friends(name forgot), make a new
>> language, it very same like with my thoughts, and it can focus CSS,
>> because the AJAXing. Before that I not intrest in CSS. After, I make a
>> new language too by employing ANTLR. I first apply for ant build file.
>> Months ago, E4 hot. at meanwhile, I need a UI builder, so I dive into
>> CSS sea. at this time, I feel, while CSS strange and why I accept it
>> before? My other application give me an answer, it mix
>> responsibilities. I not participated CSS forum. maybe I should. IMO,
>> CSS self, in CHINA says, not a man, not a ghost.
>> So, I said, maybe not only the parser.:)
>>
>> And I still wanna hear Steve about legacy of SWT.:)
>> Thank you.
>>
>> Regards,
>> Qinxian
>>
>> 2008/8/9 Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>:
>> >
>> > I'm not sure why we'd want to write our own SAC parser. Its a lot of
>> > work
>> > and there are clearly existing technologies which, while maybe not
>> > perfect
>> > fits, are better than starting from scratch.
>> >
>> > I'd much rather work with an existing community supporting Flute or
>> > Batik
>> > (assuming such communities exist, the Flute files are all 2002 so not
>> > clear
>> > if its dead code or not). Just as with Eclipse, you see if the
>> > community is
>> > open to making the changes you need. If they are, you help make those
>> > changes. This gets you the technology you need, and meanwhile furthers
>> > that
>> > community. Everyone wins! And its a very efficient use of developer
>> > resources which are always scarse. I'd rather spend those cycles doing
>> > something more specific to Eclipse (like nice style sheets, like a UI
>> > model,
>> > etc.).
>> >
>> > Regards,
>> > Kevin
>> >
>> >
>> >
>> >
>> > "向雅" <fyaoxy@xxxxxxxxx>
>> > Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
>> >
>> > 08/08/2008 05:30 PM
>> >
>> > Please respond to
>> > E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>> > To
>> > "E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>> > cc
>> > Subject
>> > Re: [eclipse-incubator-e4-dev] CSS namespaces
>> >
>> >
>> >
>> >
>> > Yes, and maybe not only a parser.
>> >
>> > SWT burden lots of legacy, which I not known about, and nice to hear
>> > details.
>> >
>> > 2008/8/9 Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>:
>> >>
>> >> Thanks for moving the comment to this thread. I still don't understand
>> >> what
>> >> you are saying though :)
>> >>
>> >> Do you mean we should implement a CSS parser from scratch rather than
>> >> use
>> >> batik or flute?
>> >>
>> >> Also not sure about your comment on SWT. It has lots of legagy burden,
>> >> Steve will tell you!
>> >>
>> >> Regards,
>> >> Kevin
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> "向雅" <fyaoxy@xxxxxxxxx>
>> >> Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
>> >>
>> >> 08/08/2008 12:56 PM
>> >>
>> >> Please respond to
>> >> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>> >> To
>> >> "E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>> >> cc
>> >> Subject
>> >> Re: [eclipse-incubator-e4-dev] CSS namespaces
>> >>
>> >>
>> >>
>> >>
>> >> Since the current CSS shoes not fit our feet, why not consider a fully
>> >> new
>> >> CSS?
>> >>
>> >> And SWT has not any legacy burden and weight.
>> >>
>> >>
>> >> 2008/8/9 Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>:
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>> Angelo brought up CSS namespaces, I think this is an important topic
>> >>>> that hasn't been discussed here yet.
>> >>>
>> >>> Sigh... yes.
>> >>>
>> >>>> The question is how to specify
>> >>>> custom widget types in CSS. With SWT, the widget names are
>> >>>> unambiguous,
>> >>>> but custom widgets can involve name collisions.
>> >>>>
>> >>>> Using CSS namespaces would be an option, although I would then opt
>> >>>> for
>> >>>> using a default namespace for SWT to avoid clutter. The CSS could
>> >>>> look
>> >>>> like this:
>> >>>>
>> >>>> @namespace "org.eclipse.swt.widgets";
>> >>>> @namespace my "my.name.space";
>> >>>>
>> >>>> Label {
>> >>>> color;red;
>> >>>> }
>> >>>>
>> >>>> my|Label {
>> >>>> color;red;
>> >>>> }
>> >>>>
>> >>>> On the other hand, some frequently used SWT widgets live in
>> >>>> "org.eclipse.swt.custom" (CLabel, CCombo, CTabFolder, ...), so those
>> >>>> would have to be prefixed as well (which I somehow dislike):
>> >>>>
>> >>>> swtcustom|CLabel {
>> >>>> color: blue;
>> >>>> }
>> >>>
>> >>> Agree, I dislike it too. It's annoying to clutter the typical case
>> >>> (SWT
>> >>> widgets, regardless of whether they are custom or not).
>> >>>
>> >>>> Moreover, CSS 3 is not yet widely adopted and the available parsers
>> >>>> do
>> >>>> not support it out-of-the-box.
>> >>>
>> >>> Good point.
>> >>>
>> >>>> An alternative to CSS namespaces could be some kind of mapping
>> >>>> between
>> >>>> widget classes and CSS element names.
>> >>>
>> >>> I think this is a reasonable approach. Extended widgets outside of SWT
>> >>> would
>> >>> need some form of qualified name, not so much to prevent clashing with
>> >>> SWT
>> >>> since presumably everyone avoids that, but to prevent clashing with
>> >>> each
>> >>> other. The element names can be whatever we want them to be, since
>> >>> its
>> >>> our
>> >>> code that'll do the mapping from CSS to widget method calls. So we
>> >>> could
>> >>> solve it without resorting to CSS name spaces, for example by
>> >>> requiring
>> >>> that
>> >>> extended widgets register their names with us in some qualified
>> >>> fashion
>> >>> (e.g. NebulaGallery). Kinda hacky but would work.
>> >>>
>> >>> Kevin
>> >>>
>> >>> _______________________________________________
>> >>> eclipse-incubator-e4-dev mailing list
>> >>> eclipse-incubator-e4-dev@xxxxxxxxxxx
>> >>> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> 致敬
>> >> 向雅
>> >> _______________________________________________
>> >> eclipse-incubator-e4-dev mailing list
>> >> eclipse-incubator-e4-dev@xxxxxxxxxxx
>> >> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>> >>
>> >>
>> >> _______________________________________________
>> >> eclipse-incubator-e4-dev mailing list
>> >> eclipse-incubator-e4-dev@xxxxxxxxxxx
>> >> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > 致敬
>> > 向雅
>> > _______________________________________________
>> > eclipse-incubator-e4-dev mailing list
>> > eclipse-incubator-e4-dev@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>> >
>> >
>> > _______________________________________________
>> > eclipse-incubator-e4-dev mailing list
>> > eclipse-incubator-e4-dev@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>> >
>> >
>>
>>
>>
>> --
>> 致敬
>> 向雅
>>
>> _______________________________________________
>> eclipse-incubator-e4-dev mailing list
>> eclipse-incubator-e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>>
>
>
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
>
--
致敬
向雅
