On 2010-11-01, at 13:32, Max Carlson wrote:
> On 11/1/10 7:41 AM, P T Withington wrote:
>>
[...]
>> I propose that we take the "best parts" from each solution:
>>
>> a) Change the default inherit behavior of CSS properties to match the
>> standard.
>
> Agreed.
>
>> b) Custom CSS properties default to not inheriting.
>
> Agreed.
>
>> c) Implement the CSS `inherit` keyword so that you can override
>> non-inheritance in a style sheet.
>
> Seems neccessary, so agreed.
>
>> d) Add a boolean `inherit` property to<attribute> for specifying whether a
>> custome `style` name defines a CSS property that inherits or not.
>
> I'm still concerned about colliding 'inherit' values. Should we warn (with
> Debug.info) when there's a collision?
I think this will only be an issue if abused. I expect the typical use will be
in a class or mixin where you are defining an API, and as a part of that the
CSS styling API. If you go willy-nilly adding CSS properties all over the
place, you will surely get in trouble; but a judicious design should be fine.
As long as you are using just standard CSS properties, you won't even have to
think about this detail.
>> e) For backwards compatibility, when no applicable CSS style applies AND
>> there is no fallback (mostly likely an old-school `value="$style{'...'}`
>> binding), retry assuming the property inherits; issue a warning in debug
>> mode. Could be an 'info' level message so they can be silenced globally, if
>> necessary.
>
> Seems good to me. That way, folks can filter out/ignore the Debug messages
> and fix them later. IWBRN if we could deprecate value="$style{'...'}"
> altogether - perhaps we should warn for this also? There are just too many
> mechanisms in place. I suspect not many people are using <attribute
> style="..." .../> yet, so this would be helpful.
That seems like a good idea.
This work is being tracked at
http://jira.openlaszlo.org/jira/browse/LPP-9493
