My thought on the matter.. I like this idea that bret mentioned, and
elliot mentioned too, regarding resource names and CSS. I wrote this
earlier and on the iPhone. I like typing on it, but you may notice
mistakes ;).
I'd like to extend the idea to allowing 'replaceable=true' to be used
without a 'src=xxx.jpg' pair present, forcing that attribute on the
tag to be defined using CSS only. The shipped stylesheet is then
properly the default and you know you are done cssing things when you
remove the last 'src' attribute from the lzx codebase.
If we want to be strict about css as a language thing then a
'__CSS__'' attribute could be applied universally-across-tags that
lists a comma sep'd list of attributes that CSS must override - or
generate an error.
(pause- did everyone know you can use a double underscore as an
attribute name? I like this convention, from python, when passing
metadata about classes into the system or framework. Neat.)
So what it comes down to is if an element is going to be skinned then
putting the default value in the code doesn't really sit well in the
larger picture anyway. the debugger output and strictness are worth
it, and code should stay separate.
Okay, important, the problem with the last bit is that the Compile
time resource tag will complain about not having a src attribute (and
an extraneous replaceable?) and the RUN-time init CSS processor won't
have a chance to do anything about that.
I bet alot of folks would tend to think CSS happens first. Would you?
CSS is applied after everything hss been parsed. A supposed "first
pass" of the CSS engine *could* lexically alter the source file before
compile, and before the run time portion does the same on dynamic
elements. that is not exactly straightforward to do, a little messy too.
If CSS could get a 'first shot' (adding attributes for instance) at
the source then this could be solved centrally. In a roundabout way,
hope this explains why things are the way they are.
(CSS rocks, thanks ben!!!)
On Aug 29, 2007, at 12:40 PM, Bret Simister
<[EMAIL PROTECTED]> wrote:
I prefer putting the responsibility on the developer creating the
library, rather than on the developer using it.
Hence,
<!-- mylibrary.lzx -->
<library>
<resource name="logo" src="logo.png" replaceable="true" />
</library>
would allow a developer using the library to write the following
<canvas>
<inlcude href="mylibrary.lzx" />
<resource name="logo" src="logo2.png" />
</canvas>
and see no warnings upon compile. This seems the cleanest approach
to me.
It lets the library developer be explicit about which resources were
designed
to be replaced.
I am also OK with Henry's suggestion about using a compiler flag
to show warnings
when you need to check for resource conflicts. The nice thing about
that approach is that
it has minimal impact upon the language.
-Bret
On Wed, Aug 29, 2007 at 8:03 AM, Elliot Winard wrote:
I can see something like that working -
<resource name="logo" src="blah.png" force="true" />
If the force attribute is present, it overwrites other declarations
of logo and does *not* emit a warning.
