2 CSS questions

[onetitfemme]

1._ How can you stop a browser from displaying horizontally floating
objects in new lines once they should not be shrunk any longer?
The browser should then show a horizontal scrollbar. I know horizontal
scrollbars are no good but I would rather have them than having the
page display in an awkward, uncontrollable way.
As I understand, designers used to go the monkey way and just have a
line as a picture with a certain width to force this behavior, but I
could imagine there are better ways to do that.
..
2._ Say you have a style sheet that looks fine for the most part, but
there are a few properties (not the whole style for a
selector/class/id) here and there that must be adjusted depending on
the browser instead of having a totally different style page for each
OS + Browser (version) combination
Also, there are ways to zipped pages before sending them and have
browsers unzip them. Can the same be achieved with style pages/files?
..
How would you do these things?
..
thanks
otf

[Chris Beall]

onetitfemme wrote:

1._ How can you stop a browser from displaying horizontally floating
objects in new lines once they should not be shrunk any longer?
The browser should then show a horizontal scrollbar. I know horizontal
scrollbars are no good but I would rather have them than having the
page display in an awkward, uncontrollable way.
As I understand, designers used to go the monkey way and just have a
line as a picture with a certain width to force this behavior, but I
could imagine there are better ways to do that.
otf,

If you can define "once they should not be shrunk any longer" in terms
that a browser can understand (place them into a div, perhaps), then you
can use min-width: xxx in the stylesheet. IE 6 will cheerfully ignore
you, but others should comply.

I didn't understand the part about "have a line as a picture with a
certain width", but you might be interested in the info at
http://pages.prodigy.net/chris_beall...ge%20size.html, especially
the 'Image size samples' link.
.
2._ Say you have a style sheet that looks fine for the most part, but
there are a few properties (not the whole style for a
selector/class/id) here and there that must be adjusted depending on
the browser instead of having a totally different style page for each
OS + Browser (version) combination
Avoidance is the way I would go. First, don't design with IE, as it is
the odd duck in the world today. If you use clean, validated HTML and
CSS, you should have little trouble getting something that works fine in
all other browsers, without any need for exception cases. Try to avoid
pixel-perfect alignment; keep everything loosely coupled.

Then look at the page with IE (yuck!). Now you have to decide how much
to kowtow to IE. If you're getting paid to do this for someone else,
you'll have to make it look nice. If not, you can choose to let IE's
warts show and let MS take the heat. Regardless, there are several 'IE
CSS hack's that you should be able to find with Google or via specific
questions (preferably with a URL pointer) to this group.
Also, there are ways to zipped pages before sending them and have
browsers unzip them. Can the same be achieved with style pages/files?

Hey, that's 3 questions! Anyway: No. Don't worry about it. If total
page size concerns you, look at reducing the size of the images first,
second, and third. If you get to fourth, split the page into multiples.

Chris Beall

[kchayka]

Chris Beall wrote:

I didn't understand the part about "have a line as a picture with a
certain width"

Sounds like the old transparent gif kludge, to me.

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.

[onetitfemme]

OK, this is why I am asking so many questions about CSS.
..
When you look for some CSS related info all you basically find is the
w3c normative documents and lots of partial remedies to "quirks",
ad-hoc cooking and some other things that sound more like black magic
;-)
..
Maybe there is a "reason why" I don't get it, probably because I
am not a designer myself, I come from, as they call them, "hard
sciences"/programming background and I find a little weird (should I
say funny?) the way designers code ;-), but I have always wondered why
they haven't come up with the idea of coding the syntax of style sheets
in a simple way. Say only declarations and conditional statements. Like
this:

$<VAR_NAME>:= "OPTION_1" | "OPTION_2" | "OPTION_3";

$UA= @HTTPRequestHeader.User-Agent;

<ifs (@UA==@VAR_NAME)>
then include this and that property and value for this and that
browser
<elses>
...
</ifs>

Of course you could actually code and serve the actual style sheet in
response to one request and there will be definitely more than that,
but the basic idea is there.

Why haven't designers and standard settings people come out with
something like that?

Are there political reasons? I can see a void between what the norm
"should be" and the world as it is, and this void has been there
for quite some time.

Thanks
otf

[Chris Beall]

onetitfemme wrote:

OK, this is why I am asking so many questions about CSS.
.
When you look for some CSS related info all you basically find is the
w3c normative documents and lots of partial remedies to "quirks",
ad-hoc cooking and some other things that sound more like black magic
;-)
.
Maybe there is a "reason why" I don't get it, probably because I
am not a designer myself, I come from, as they call them, "hard
sciences"/programming background and I find a little weird (should I
say funny?) the way designers code ;-), but I have always wondered why
they haven't come up with the idea of coding the syntax of style sheets
in a simple way. Say only declarations and conditional statements. Like
this:

$<VAR_NAME>:= "OPTION_1" | "OPTION_2" | "OPTION_3";

$UA= @HTTPRequestHeader.User-Agent;

<ifs (@UA==@VAR_NAME)>
then include this and that property and value for this and that
browser
<elses>
...
</ifs>

Of course you could actually code and serve the actual style sheet in
response to one request and there will be definitely more than that,
but the basic idea is there.

Why haven't designers and standard settings people come out with
something like that?

Are there political reasons? I can see a void between what the norm
"should be" and the world as it is, and this void has been there
for quite some time.

Thanks
otf

otf,

Yes, you can test for UA and serve tailored HTML/CSS based on that test.
PHP is one way, there are others. Some reasons you don't often see
that discussed here:
- It's a lot more work.
- Testing for UA is not a well-developed science, and the UAs keep
changing.
- Some, perhaps many, of the people who post here are creating sites
which will be hosted by an ISP that provides only basic services (or
charges more than the developer wants to pay for additional services).
That limits them to HTML, CSS, and pre-processors, none of which can
dynamically respond to the type of UA.
- Javascript can be used at the client side to do UA 'sniffing', but
it's still unreliable (most people copy a sniffer they found on the web,
without regard to how old or robust it is) and not everyone has
JavaScript enabled.
- Did I mention that it's a lot more work?

Optimistic view:

As UA creators gain experience, they will see and embrace the advantages
of writing 'compliant' browsers. Gradually the need for 'black magic'
tricks will diminish. Right now, IE 6 is the conspicuous black sheep;
whether IE 7 will be better remains to be seen. If the users could be
educated, it would become moot, since there are several free
alternatives available. In practice, this is not likely to happen
unless some legal action requires MS to ship their operating systems
without a browser, forcing the user to make a choice other than "it came
with the system, so that's what I'll use."

It's not politics, it's business. W3C sets standards, with the goal of
complete interchangeability (and, let's be frank, more interest in
content than presentation). MS implements subsets and extensions,
because they want users to build a dependence on their unique
implementation. Interchangeability with anything other than MS products
is Bad. Other vendors, struggling to compete, implement to the specs
and add value via functions that extend in directions the W3C has not
addressed (tabbed browsing, popup blockers, etc.).

MS did not invent this technique. Another large computer company, known
by its THREE initials, did this, successfully, for years. Now they tout
open standards. The change was driven by users, who gradually realized
that they were being nailed into a proprietary box and didn't like it.

Chris Beall

[kchayka]

onetitfemme wrote:

<ifs (@UA==@VAR_NAME)>
then include this and that property and value for this and that
browser
...

Why haven't designers and standard settings people come out with
something like that?

This is not a new idea - it's called browser sniffing and has been
around for years. It's also inherently unreliable, so don't even bother.

Taking advantage of parsing bugs or (un)supported features, as bad as it
may be, is much more reliable than browser sniffing. You can complain
about the state of things all you want, but it's not likely to change
anything. Pick a battle worth fighting and move on.

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.

[VK]

Chris Beall wrote:

Maybe there is a "reason why" I don't get it, probably because I
am not a designer myself, I come from, as they call them, "hard
sciences"/programming background and I find a little weird (should I
say funny?) the way designers code ;-), but I have always wondered why
they haven't come up with the idea of coding the syntax of style sheets
in a simple way. Say only declarations and conditional statements. Like
this:

$<VAR_NAME>:= "OPTION_1" | "OPTION_2" | "OPTION_3";

$UA= @HTTPRequestHeader.User-Agent;

<ifs (@UA==@VAR_NAME)>
then include this and that property and value for this and that
browser
<elses>
...
</ifs>

Of course you could actually code and serve the actual style sheet in
response to one request and there will be definitely more than that,
but the basic idea is there.

Why haven't designers and standard settings people come out with
something like that?

They did actually. If we remember that CSS is *not* a programming
language but just a set of styling instructions, then it already has
what you're asking about.

1) Any illegal / unrecognized rules are irnored
2) All recognized rules are applied in order they are declared in the
sheet.
Note: this priority order can be changed by using !important modifier

Taking this (intentionally brocken) sample:

<style type="text/css">
SPAN.PseudoLink {
font-color: #0000FF;
font-decoration: underline;
cursor: foobar; cursor: hand; cursor: pointer;
}
</style>

As there is not "foobar" cursor style, it will be silently ignored by
all browsers.

IE below 6.0 doesn't understand "pointer", so it will ignore both
"foobar" and "pointer" and apply "hand"

IE 6.0 or greater understands both "hand" and "pointer". So it will
ignore "foobar", apply "hand" and right away apply "pointer". As
"pointer" goes after "hand" it will have higher priority so the actual
pointer style will be standard-compliant "pointer".

Any other modern standard-compliant browser will ignore "foobar" and
"hand" and use "pointer".

The reason why you don't see this very often in standards-targeted
newsgroups is phychological, not technical. The problem is that W3C CSS
validator doesn't accept idea of "either this or that". For him there
is only one correct W3C variant, so such CSS as above will be never
validated. And a lot of people simple cannot use CSS until it's OK'ed
by W3C.

Also for *inline* style blocks you can use conditional comments. This
is *much* less convenient *in relation to styles*. So the original
sample could be presented then as:

Common block:

<style type="text/css">
SPAN.PseudoLink {
font-color: #0000FF;
font-decoration: underline;
}
</style>

For IE below 6.0:

<!--[if lt IE 6]>
<style type="text/css">
SPAN.PseudoLink {
cursor: hand;
}
</style>
<![endif]-->

For IE 6.0 or greater and all other browsers:

<![if gte IE 6]>
<style type="text/css">
SPAN.PseudoLink {
cursor: pointer;
}
</style>
<![endif]>

[onetitfemme]

// __ Chris Beall

Yes, you can test for UA and serve tailored HTML/CSS based on that test.
PHP is one way, there are others. otf: But I am talking about actually programming the style sheets with
a few conditionals, declarations and such basic things
.. Some reasons you don't often see that discussed here:
- It's a lot more work. otf: How so? Notice that I am not talking about a full blown
programming lang here.
.. - Testing for UA is not a well-developed science, and the UAs keep changing. otf: Part of the stylesheets' algo would be noticing when there are
new UAs/browsers out there and emply some logic (even if based on
heuristics) to serve the most probable style or default to a "nomative"
browser stated in the TOS, of the business/site.
.. - Some, perhaps many, of the people who post here are creating sites
which will be hosted by an ISP that provides only basic services (or
charges more than the developer wants to pay for additional services).
That limits them to HTML, CSS, and pre-processors, none of which can
dynamically respond to the type of UA. otf: Well, yes! I never thought of that, but, of course, as we know
this isn't exactly a technical problem.
.. - Javascript can be used at the client side to do UA 'sniffing', but
it's still unreliable (most people copy a sniffer they found on the web,
without regard to how old or robust it is) and not everyone has
JavaScript enabled. otf: Yeah! Many people do disable JavaScript (I do) that is why
relying on the UA is better. IMHO
.. Optimistic view: otf: I read about MS surprising (as the journalist put it) the EU
oppening MS source code. How big MS has changed after Linux, ...
Firefox, .... came out!!!
.. It's not politics, it's business. otf: I meant the "politics of business"
..
// __ kchayka Taking advantage of parsing bugs or (un)supported features, as bad as it
may be, is much more reliable than browser sniffing. otf: I always thought of them as two overlapping/complementary
problems
.. You can complain about the state of things all you want, but it's not
likely to change anything. Pick a battle worth fighting and move on. otf: I think any "right" and "just" battle worth fighting as long as
you fight it the true/smart way.
..
// __ VK They did actually. If we remember that CSS is *not* a programming
language but just a set of styling instructions, then it already has
what you're asking about. otf: But then people use JS on the client side for their cooking ...
.. 1) Any illegal / unrecognized rules are irnored
2) All recognized rules are applied in order they are declared in the
sheet. otf: The actual problem is that recognized rules are not properly
applied.
.. Note: this priority order can be changed by using !important modifier otf: the "!important" modifier is one of the funniest things I have
found in my programming career
.. As there is not "foobar" cursor style, it will be silently ignored by all browsers.
otf: But why even serving data that is not used anyway,
.. The reason why you don't see this very often in standards-targeted
newsgroups is phychological, not technical. The problem is that W3C CSS
validator doesn't accept idea of "either this or that". For him there
is only one correct W3C variant, so such CSS as above will be never
validated. And a lot of people simple cannot use CSS until it's OK'ed
by W3C.

otf: Well we might be talking about tirany of standards here
..
Thanks

[onetitfemme]

I was thinking about something that I might not have understood from
your comments.
..
I have always believed the UA that the different kinds of browsers
(should) send as part of the request headers to the server is the same
that is indicated if client side JS-based browser sniffers are used.
..
If this is not so, this is a good case of black magic and I would like
to know the specifics of it. Which browsers don't show the same id?
..
I do know that request headers are just a string sent as part of a
connection hand shake and they could be reset/altered I am not talking
about this fact.
..
Thanks
otf