Re: [css3] [css21] browser specific CSS

On 4/21/2011 1:12 AM, Alan Gresley wrote:
> On 21/04/2011 3:44 PM, Glenn Linderman wrote:
>> On 4/20/2011 10:01 PM, Boris Zbarsky wrote:
>>> On 4/21/11 12:39 AM, Glenn Linderman wrote:
>>>> I see! So that explains why the sample I sent looks the way it does...
>>>> the intrinsic width is calculated, the container is set to that size,
>>>> the height is too big, and so the scrollbar is added, which subtracts
>>>> from the space available for the content, so it gets even taller, and
>>>> multiple lines are used per cell even though there is plenty of blank
>>>> space to the right.
>>>
>>> Yes, that is exactly what happens.
>>
>> Thanks for sticking with me until I understand it.
>>
>> Produces pretty sad results. Chrome does the same, apparently. Opera and
>> IE do better. Dunno about the rest. Alan demonstrated what appears to be
>> a hack depending on current but non-standard behavior that improves the
>> results.
>
> Please don't see it as a hack.


The reason I called it a hack was because when reading the standard to 
figure out why it worked, it seems to fall into a case that is 
explicitly not defined by the standard.  So, why shouldn't I see it as a 
hack?  I guess, though, the hack is using the float to get the scrollbar 
into a reasonable position, not your technique of adjusting the 
margin... because the float is where we enter non-standardized territory.


> If you had declared a width value on the
> floated element with overflow, then you would not need to give extra
> magical CSS to fix something that is way to esoteric in the first place.
> I simple declared width makes an authors job easier, one demo [1] (BTW,
> it's an experiment, not grounds to say that there are bugs).


But I don't know the width... nor even the number of columns, as in the 
actual site I'm working on, that is user selectable.  So the choices 
seem to be:

Say nothing except the height constraint, and get a scrollbar on the 
right edge of the page, far away from the table (sometimes; sometimes 
the data fills the width of the screen).

Say float, and wind up in non-standard territory, where some browsers 
give enough width for the data + scrollbar, and some don't.

Say float, and use your margin technique to make more browsers give 
enough width for the data + scrollbar.

Preprocess the data, and attempt to predict how much width will be 
needed for the browser to properly render the data, and then tell the 
browser that width.  This would basically require reimplementing the 
browser's rendering algorithms on the server, before generating the 
HTML, or hoping the user has Javascript enabled, and doing it in 
Javascript in the browser.

And none of those keep the (dynamic, for the real application) column 
headers visible for the users).  Nor provide for a way to make the 
column headers the "same width as" the table columns, if done outside 
the table.... "same width as" and "same height as" could be really 
useful in lots of places in CSS, by the way, as could arithmetic for 
lengths, as in 6em + 10%.


>> Helpful until something changes. This is why we web authors
>> need to do browser brand and version sniffing, because to get pleasing
>> results, we have to go into areas that are not standardized.
>
>
> You should say what is not interoperable (consistent across browserland).


Well, I'm saying what is not standard.  Right now it is somewhat 
interoperable, among the 4 browsers I test with, and the 5 you tested 
with.  But the fact that Safari required an extra tweak, makes me 
concerned that some other browser might require yet another tweak.  The 
margin technique doesn't bother the two browsers that already produced 
pleasing results. The Safari tweak doesn't bother the other 4 browsers. 
  This is nice, but it depends on things that are not standardized, and 
therefore unknown how untested browsers will behave, and are subject to 
change for future versions of tested browsers.  That's a pretty shaky 
foundation for a technique.  Happily, my users for that application all 
use Firefox (except a few that use Chrome), so I'm somewhat OK, for the 
moment... except I've lost my scrolling tbody (but Chrome users never 
got that anyway, but the Firefox ones loved it).


>> In _this_
>> case, code can be written that happens to work similarly enough in 5
>> browsers (per Alan, I don't have Safari installed here), that it seems
>> that brand and version sniffing is not necessary for current browser
>> versions... but I don't know if that picture changes if more browser
>> brands are tested, and as soon as one of them changes something in their
>> non-standard-prescribed behavior, such may be necessary, or a wholesale
>> rewrite of the CSS for this case.
>
>
> Is this about auto width floats with overflow or are you applying this
> generally about CSS? You don't need to browser sniff to code CSS and
> have it look the same in all browser (the exception is IE depending on
> mode).


Yes, this is about auto width floats not having a standard size or 
behavior across browsers, particularly with overflow: auto.

But yes, I'm also generalizing to point out that all the many places 
where CSS leaves things undefined, can cause similar situations, when 
CSS doesn't provide a standard technique for providing a decent looking 
solution.  And then there are potential bugs, it seems that your extra 
Safari technique is working around a non-conformance in Safari, as far 
as I can read the standard.

I've only isolated and demonstrated this one case so far... I've been 
using non-HTML5 DOCTYPE and fighting the older browser versions for 
years, however, and find it extremely hard to believe there won't be 
other cases.  Whether they will all be solvable without browser sniffing 
will have to wait and see.


>> Having a simple CSS way to sniff
>> browser brands and versions would make me feel a lot more comfortable
>> with using Alan's hack.
>>
>> And, of course, none of this addresses keeping the headers and footers
>> visible while scrolling.
>
>
> This really has nothing to do with tables. I have showed you the fix,
> which is here.
>
> http://css-class.com/test/css/overflow/table-inside-auto-width-float-overflow.htm


Right.  It is really Glenn's hack, desperately trying to use 
auto-width-table-inside-auto-width-float to get the scrollbar put in a 
reasonable spot now that firefox dropped scrolling tbody, fixed by 
Alan's suggested margin technique.  And I agree it isn't specific to 
tables; it really doesn't matter what is inside the auto-width-float, 
but tables are my extremely variable size use case here.


> The problem is the use of auto width floats with overflow. There is no
> interoperability among browsers when you use this potent mixture.
>
> http://css-class.com/test/css/overflow/block-inside-auto-width-float-overflow.htm
>
> Instead of hacking, just don't use auto width floats with overflow.


Sure.  Just don't do it.  Just use VisiCalc.

Just let the scrollbar be on the right margin for tables that are only 
10-70% of the screen width, and hope the user can find it (when the 
tables wind up being 70% or wider, the scrollbar is "close enough" to be 
more easily noticed, in my opinion).  Most of them probably would, 
eventually, because they are expecting more data than they see.  But it 
looks gross, and certainly isn't intuitive.

Or, just rewrite the browser table auto width feature in the server or 
Javascript, so a specific size can be given. Just a SMOP, LOL.


> [1] http://css-class.com/test/demos/xml/baptism-xhtml.htm

Received on Friday, 22 April 2011 02:33:48 UTC