- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 21 Apr 2010 08:49:42 -0700
- To: Mikko Rantalainen <mikko.rantalainen@peda.net>
- Cc: www-style list <www-style@w3.org>
On Wed, Apr 21, 2010 at 12:12 AM, Mikko Rantalainen <mikko.rantalainen@peda.net> wrote: > Tab Atkins Jr. wrote: >> On Fri, Apr 16, 2010 at 7:34 PM, Andrew Fedoniouk >> <news@terrainformatica.com> wrote: >>> Tab, are you trying to re-introduce display-model and display-role from >>> here: http://www.w3.org/TR/2002/WD-css3-box-20021024/#L706 >>> ? >> >> Yes, precisely. That's the draft that I took some text from, actually. > > That would have been nice to point out in the beginning. Could you > elaborate about the important differences between your latest version > and the old working draft? I did mention it in the first paragraph of my original message, though I didn't specify exactly which document I took it from. Mea culpa if that was important info. There are three areas of difference between my draft and the older draft: 1. Some names have been changed 2. All corner cases are specified (the older draft forgot to address a few places) 3. A slightly different mapping between some of the single-keywords forms and the double-keyword forms. I don't think the differences here are significant. > I agree with the idea of splitting the 'display' property in parent and > child parts. > > Why you did not use 'display-model' and 'display-role' as previously > specified? Do you believe that 'display-inside' and 'display-outside' > are more clear? Yes, it took me some time before I finally got it sorted out in my head precisely what -model and -role *meant*, and stopped confusing the two. Maybe I'm abnormal. ^_^ I think that -inside and -outside describe well what the values apply to. I'm still open to other names > I agree with your reasoning about list-item and the I think that it > requires something pretty special. I'm afraid that for backwards > compatibility and special side-effects required for current definition > of 'display: list-item', the only logical choice is a third display > property. I don't know if it should be called 'display-extras' or > 'display-side-effects' or 'display-magic' or 'display-compatibility' but > it would make following > display: list-item; > a short hand for > display-outside: block; > display-inside: inline; > display-extras: list-item; /* ::marker and counter magic */ Well, display-inside is 'block' for list-item, but otherwise yes. > I'd suggest using the name 'display-compatibility' because hopefully the > list-item is the only feature ever needing this hack. Using the word > 'compatibility' in the property name should be make it obvious that new > features should not use this property. On the other hand, there may not > ever be a time when an UA vendor could stop supporting 'display: > list-item' (in favor of newer features). I think the word > 'compatibility' should be used only if the feature would be deprecated > in the future. There is no reason whatsoever to deprecate display:list-item. The only thing wrong with it is that it's exactly like block, but with magic, so anytime we have to say something about display:block right now, we have to remember to include list-item. If we can prevent that by separating out the magic, then everything's fine. Keeping display:list-item as a shorthand is perfectly useful and fine for content to continue using. > In addition, I agree with Andrew Fedoniouk that splitting the 'display' > property does not change anything in itself. However, I still believe > that this change would be beneficial in the long run, because it would > simplify defining new features as Tab Atkins Jr. reasoned. In addition, > it would make explicit to UA vendors that the engine must be able to use > separate algorithms for the the inside and outside of any element. That's not *quite* accurate. Splitting the display property *would* have an effect right now, namely that of enabling list-items and table-cells to be tables themselves. This is very minor right now, though. The real effect comes in later, when we properly introduce the template and flexbox display types. These really *are* useful to be applied directly to a list-item or table-cell. This also prevents us from being forced to introduce inline-template and inline-flexbox directly, which is just silly imo. > Why was the previous split (display-model/display-role) abandoned? It > does not exists in latest draft as far as I know. Not sure. ~TJ
Received on Wednesday, 21 April 2010 16:16:46 UTC