- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Tue, 27 Nov 2007 12:00:01 -0800
- To: Todd Russell <groovechicken@gmail.com>
- CC: www-style@w3.org
Todd Russell wrote: >> I suggest to add support(attribute[,value]) function instead. >> >> So this: >> >> @media screen and has(renderer:Trident) >> { >> a.exlink {display:inline-block;} >> } >> >> can be rewritten as >> >> @media screen and support( display, inline-block ) >> { >> a.exlink {display:inline-block;} >> } >> @else >> { >> a.exlink {display:block; } >> } > > Sorry to butt in, but I couldn't help noticing something obvious. > Forgive me if this has been discussed already as I am new around here. > > Why not the following?: > > @media screen and > { > a.exlink {display:inline-block;} > } > @else > { > a.exlink {display:block; } > } > That will complicate things significantly. Parsing errors handling is established already. Say someone will try to use our flex units: @media screen and { a.exlink { width :2*; } p { width :200px; } } @else { a.exlink { width :200px; } } CSS mandates that height :2*; has to be ignored until closing ';' if UA does not recognize such units. And it makes sense. Also I believe that almost all CSS parsers establish attribute only parsing context. It would be difficult to redesign such parsers to support rollbacks of sets of attributes. As in our case flex units makes sense only if UA support layout manager module (it uses, say, 'flow' attribute) then we can write this as @media screen and support(flow) { a.exlink { width :2*; } p { width :200px; } } @else { a.exlink { width :200px; } } and this will work. Typical implementation of support(flow) can be table-driven in UA's source code thus pretty reliable and straightforward - good chance that it will reflect actual set of supported attributes and features. Andrew Fedoniouk. http://terrainformatica.com
Received on Tuesday, 27 November 2007 20:00:24 UTC