17
edits
Line 113: | Line 113: | ||
Sharing between borders of same weight is IMHO critical for people who use double borders (or groove, ridge, etc...). Furthermore, when there is no mean to decide which border should win, instead of "punishing" the "bad designer" with an arbitrary winner, why not just do something useful (double borders, etc...) ? If the designer is not pleased by the rendering, he will change his table for a correct design. (Nota: I based some of my comments on a wrong assumption, see the edit of border sharing note above, so I now think that we definitively shouldn't share the corner between borders of different widths, because there is no mean to defeat this) --[[User:frnchfrgg|FrnchFrgg]] | Sharing between borders of same weight is IMHO critical for people who use double borders (or groove, ridge, etc...). Furthermore, when there is no mean to decide which border should win, instead of "punishing" the "bad designer" with an arbitrary winner, why not just do something useful (double borders, etc...) ? If the designer is not pleased by the rendering, he will change his table for a correct design. (Nota: I based some of my comments on a wrong assumption, see the edit of border sharing note above, so I now think that we definitively shouldn't share the corner between borders of different widths, because there is no mean to defeat this) --[[User:frnchfrgg|FrnchFrgg]] | ||
I am really concerned about the discussion here. It does not answer the question of code bloat. Any change in the implementation should result in less code than we have now. I will resist any proposal that creates border segments with more than four edges. The question should be: what we need to do to become CSS 2.1 compliant, not what fancy corners one could create. There is http://www.w3.org/TR/css3-background to discuss this. --[[User:Bernd|Bernd]] | |||
== Who paints what == | == Who paints what == |
edits