CC'ing laszlo-dev, removing some other lists... better late than never!
On 11/1/10 7:41 AM, P T Withington wrote:
On 2010-10-31, at 23:49, Fred Feng wrote:
Hi Tucker,
Thanks for bring up this topic.
Here are some of my personal opinions from a plain developer's view:
1. We must consider the impact on current user program, especially Jade;
Understood. Perhaps there is another option: When standard CSS would not give
a value and there is no fallback, try the backwards-compatible way instead. In
debug mode, issue a warning so the developer can fix their code to be standard.
2. I assume that we have tackled several NON-standard or hacking ways in our
previous project, since we will announce that OL will fully support HTML5, it
should be better to follow up the standard CSS way as much as possible;
At least to box modal feature, i don't expect it to give me any surprise if
none of its style info is list explicitly.
Yes, I want to fix this.
3. We can have a patch to fix them and mark 'inhert' or not, it works. But from
long sight, we will need more and more patchs if we don't have a clear view on
our basic discipline.
I think the basic discipline should be that there is no inheritance by default, but that
we allow the developer to create new properties that can inherit. I do not consider this
a "patch" so much as giving the developer a way to extend the set of CSS
properties and control whether or not new properties inherit or not.
On 2010-11-01, at 00:05, Max Carlson wrote:
1) doesn't seem like an option.
Well, it is the only option if we make our CSS behave according to the standard
and don't do anything else.
2) seems like a lot of work, and doesn't solve 1)
2b) is the standard way of solving 1. You declare that you want the property to inherit in
your style sheet. It is the _only_ option for non-inheriting properties. In standard CSS,
for instance, background-color does not inherit. If you want to control the background-color
of a contained node with a style on the container, you would _have_ to make a style that
applies to the contained node explicitly stating that background color should inherit.
That's the only way to do it in standard CSS. (See p. 292 of Bos& Lie "Cascading
Style Sheets" under 'The INHERIT Keyword'.)
3) seems useful for user-defined style bindings.
Yes, and per Fred's comments, I believe we need to support this. There has to
be a way for the programmer to add custom CSS properties and choose whether
that property is an inheriting property or not. I plan to add this, but I also
plan to change the default from 'inherit' to not inheriting, because that is
more standard. Most CSS properties do not inherit.
4) it doesn't seem like we can afford to do this because of 1)
Agreed. To do this would be to go further away from the standard.
Here's another idea: add an attribute to the stylesheet declaration that
toggles the behavior described in 4). That way, legacy code can act as-is, and
users can add CSS that's clearly marked to be processed according to the
standard. This would break 3) though...
Per Fred's comments, I don't think we want to endorse more non-standard
operation.
I think this situation arose because the original implementor of our CSS either
overlooked this issue or just did not understand it. This is clear from the
many test cases that fail when I enforce the standard.
Per my comment to Fred, I have a 5th option:
5) When there is no applicable CSS rule, try again with 'inherit'. In debug
mode, issue a warning.
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?
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.
