PHWinfo - Afficher un message

10/04/2008, 12h32

On 2008-04-10, dorayme <doraymeRidThis@optusnet.com.au> wrote:
> In article <slrnfvordn.6kn.spamspam@bowser.marioworld>,
> Ben C <spamspam@spam.eggs> wrote:
>> On 2008-04-06, Gus Richter <gusrichter@netscape.net> wrote:
[...]
>> > We can predict consistent behaviour as soon as we accept that:
>> >
>> > 1. The float's real estate covers that of the containing block, where
>> > both start at 0,0 (without any positioning). Either may have smaller or
>> > larger width and/or height.
>> > 2. In the instance of a float we actually 'already' have the float
>> > layered on top of the containing block with a pre-established stacking
>> > order.
>> > 3. _Without any positioning applied_ to the containing block, the float
>> > has a higher stacking order. The float is on top.
>> > 4. _With positioning applied_ to the containing block, the containing
>> > block has a higher stacking order. The float is on bottom.
>> > 5. _With positioning applied_, the stacking order may be changed by
>> > applying z-index to the containing block.
>>
>> Exactly right.
>
>
> Thanks for all the explanations in this thread. I found all of them
> ful for various reasons.
>
> On the question of predictability, to be perfectly frank, I don't *know*
> this is *exactly* right because I don't know who - really - are the "we"
> that Gus refers to. Or what - really - "predict" means here. Or even
> quite what is to be explained (there have been a few variations on a
> theme in this thread).
>
> If browsers can go different ways on some combinations, so too might
> humans. And we don't actually know if it is all consistent.
>
> It is a difficult issue and who will have the patience to look at it! I
> have this idea that the css specs set can be seen to talk to browsers
> and/or to talk to the human mind. In order to talk to browsers it has to
> initially talk to humans who program the browsers. We know for a fact
> that humans program browsers a bit differently and so this is some
> evidence that they read the same bible words differently (not complete
> evidence, they may perhaps all read it the same way but are differently
> beholden to pressures, commercial and other and ignore what they read).

Sometimes the programmers don't understand the spec, sometimes they just
get it wrong (bugs), sometimes they have something that's almost right
and mostly works (and may pre-date the spec) and that's a lot of risk to
change.

Occasionally they ignore the spec deliberately where it just seems
wrong-headed, but this is rare these days with CSS.

> Once instantiated in real code, we get machine predicticability.

Up to a point but some bugs can be very unpredictable!

> Given the same set of circumstances, they do the same thing.

Yes, although sometimes the circumstances can depend on timing, the
contents of uninitialized memory (i.e. whatever was left there by the
last program that used that bit of memory), and things well outside the
scope of what you thought was the input you were giving the program.

> Machines have little worries or doubts about the meaning of their
> instructions. If they don't understand them, they just ignore them.

They often crash too.

> And if they seem to understand them, they ipso facto do understand
> them and simply act on their understanding. And we can learn the ways
> of this machine up to a point.

Up to a point, but it's very hard to debug a program without the source
code, although this is effectively what some web developers have had to
do to improve predictability with IE.

The best advice for any web developer targetting crappy browsers is to
try to stick to the subset of the specification that does work. If you
find something that doesn't work as you expect check whether it's
actually wrong according to the spec. If it is, don't try to
second-guess it, reverse-engineer it, or touch it with a bargepole but
find some other way of doing it.

If it is wrong according to the spec it's more likely to be different in
different browsers and also in newer releases of the same browser.

> I have previously made the point in this thread that there is a lot of
> agreement among browsers on a lot of things to do with visual order
> and this speaks of an underlying logic.
>
> But there is another interesting issue to do with human mental
> ergonomics. The fit of html and css to the human mind is not exactly
> one of the wonders of the world. Not like English which ranks up there
> with the Sydney Opera House as an eighth wonder.

> If you hand picked a few people and asked them to draw what they would
> expect to see from various snippets of code, you would get a fair bit of
> agreement on a lot of things. But what things and what are the
> conditions for this imaginary experiment? Who is to be picked? Have we
> picked the wrong people if they go all wobbly or differ among
> themselves?

The problem is that what seems intuitively right in one situation is not
always what you want in another.

Take floats for example: when people use them for columns they are
surprised that the container doesn't make any height for them.

But if someone were using them to embed figures in paragraphs of text,
they would be equally surprised and annoyed if each container stretched
to fit the floats leaving big gaps between the text in each paragraph.

How to avoid annoying surprises is one of the difficult things about
designing any kind of human/machine interface.

Broadly there are two schools of thought here. Do you make a simple but
powerful system for which people have to read the manual and write
correct input (but it's for their own good), or do you give them lots of
features to do every little thing and accept any input with hidden rules
for "doing what they mean"?

Compare your old camera which had one dial for shutter speed and one for
aperture with your new one which replaced them with a button for
mountains, another one for people in front of mountains, one for the sun
rising over the same mountains, one for pictures of galloping horses,
people wearing large hats, tulips, skyscrapers, the moon, etc.

HTML/CSS seems to ended up with a bit of both design policies, to the
point where some authors are using obscure side-effects of overflow:
hidden because they understand what the machine is supposed to do and
others are setting vertical-align: middle on DIVs because they want them
vertically aligned to the middle of something.

> Thought experiments are one thing and real field tests are another
> altogether. It is well known that the world has a bad habit of biting
> the most scientific thoughts and predictions.
>
> It is easy to say stuff in hindsight. Well, let me qualify that! It is
> *not* always so easy! Some people do it brilliantly. Ben C does it
> better than anyone (at least to my ears).

Thank you

> I am not belittling the hindsight test as much as the use of the word
> "hindsight" suggests. But a hindsight test is *not* a prediction test.
>
> And, crucially, the word "prediction" is not some piece of linguistic
> magic that imprints its meaning on all mortal beings in the same way. I
> say this because there will be a lot of people who think they know
> *exactly* what is meant by *the rules predict the behaviour* and I am
> just a little bit more skeptical.
>
> I am not trying to be awkward. I *am* this without effort most of the
> time <g>

It is good to try to have an intuitive understanding of why the rules
are the way they are. There is some kind of rationale for most of it and
if you can figure it out there's much more chance you can implement it
correctly as a programmer or find the simplest ways to get the rendering
effects you want as an author/designer.

10/04/2008, 12h32	#40
Ben C Messages: n/a Hébergeur:	Re: Float and Shrinkwrap On 2008-04-10, dorayme <doraymeRidThis@optusnet.com.au> wrote: > In article <slrnfvordn.6kn.spamspam@bowser.marioworld>, > Ben C <spamspam@spam.eggs> wrote: >> On 2008-04-06, Gus Richter <gusrichter@netscape.net> wrote: [...] >> > We can predict consistent behaviour as soon as we accept that: >> > >> > 1. The float's real estate covers that of the containing block, where >> > both start at 0,0 (without any positioning). Either may have smaller or >> > larger width and/or height. >> > 2. In the instance of a float we actually 'already' have the float >> > layered on top of the containing block with a pre-established stacking >> > order. >> > 3. _Without any positioning applied_ to the containing block, the float >> > has a higher stacking order. The float is on top. >> > 4. _With positioning applied_ to the containing block, the containing >> > block has a higher stacking order. The float is on bottom. >> > 5. _With positioning applied_, the stacking order may be changed by >> > applying z-index to the containing block. >> >> Exactly right. > > > Thanks for all the explanations in this thread. I found all of them > ful for various reasons. > > On the question of predictability, to be perfectly frank, I don't know > this is exactly right because I don't know who - really - are the "we" > that Gus refers to. Or what - really - "predict" means here. Or even > quite what is to be explained (there have been a few variations on a > theme in this thread). > > If browsers can go different ways on some combinations, so too might > humans. And we don't actually know if it is all consistent. > > It is a difficult issue and who will have the patience to look at it! I > have this idea that the css specs set can be seen to talk to browsers > and/or to talk to the human mind. In order to talk to browsers it has to > initially talk to humans who program the browsers. We know for a fact > that humans program browsers a bit differently and so this is some > evidence that they read the same bible words differently (not complete > evidence, they may perhaps all read it the same way but are differently > beholden to pressures, commercial and other and ignore what they read). Sometimes the programmers don't understand the spec, sometimes they just get it wrong (bugs), sometimes they have something that's almost right and mostly works (and may pre-date the spec) and that's a lot of risk to change. Occasionally they ignore the spec deliberately where it just seems wrong-headed, but this is rare these days with CSS. > Once instantiated in real code, we get machine predicticability. Up to a point but some bugs can be very unpredictable! > Given the same set of circumstances, they do the same thing. Yes, although sometimes the circumstances can depend on timing, the contents of uninitialized memory (i.e. whatever was left there by the last program that used that bit of memory), and things well outside the scope of what you thought was the input you were giving the program. > Machines have little worries or doubts about the meaning of their > instructions. If they don't understand them, they just ignore them. They often crash too. > And if they seem to understand them, they ipso facto do understand > them and simply act on their understanding. And we can learn the ways > of this machine up to a point. Up to a point, but it's very hard to debug a program without the source code, although this is effectively what some web developers have had to do to improve predictability with IE. The best advice for any web developer targetting crappy browsers is to try to stick to the subset of the specification that does work. If you find something that doesn't work as you expect check whether it's actually wrong according to the spec. If it is, don't try to second-guess it, reverse-engineer it, or touch it with a bargepole but find some other way of doing it. If it is wrong according to the spec it's more likely to be different in different browsers and also in newer releases of the same browser. > I have previously made the point in this thread that there is a lot of > agreement among browsers on a lot of things to do with visual order > and this speaks of an underlying logic. > > But there is another interesting issue to do with human mental > ergonomics. The fit of html and css to the human mind is not exactly > one of the wonders of the world. Not like English which ranks up there > with the Sydney Opera House as an eighth wonder. > If you hand picked a few people and asked them to draw what they would > expect to see from various snippets of code, you would get a fair bit of > agreement on a lot of things. But what things and what are the > conditions for this imaginary experiment? Who is to be picked? Have we > picked the wrong people if they go all wobbly or differ among > themselves? The problem is that what seems intuitively right in one situation is not always what you want in another. Take floats for example: when people use them for columns they are surprised that the container doesn't make any height for them. But if someone were using them to embed figures in paragraphs of text, they would be equally surprised and annoyed if each container stretched to fit the floats leaving big gaps between the text in each paragraph. How to avoid annoying surprises is one of the difficult things about designing any kind of human/machine interface. Broadly there are two schools of thought here. Do you make a simple but powerful system for which people have to read the manual and write correct input (but it's for their own good), or do you give them lots of features to do every little thing and accept any input with hidden rules for "doing what they mean"? Compare your old camera which had one dial for shutter speed and one for aperture with your new one which replaced them with a button for mountains, another one for people in front of mountains, one for the sun rising over the same mountains, one for pictures of galloping horses, people wearing large hats, tulips, skyscrapers, the moon, etc. HTML/CSS seems to ended up with a bit of both design policies, to the point where some authors are using obscure side-effects of overflow: hidden because they understand what the machine is supposed to do and others are setting vertical-align: middle on DIVs because they want them vertically aligned to the middle of something. > Thought experiments are one thing and real field tests are another > altogether. It is well known that the world has a bad habit of biting > the most scientific thoughts and predictions. > > It is easy to say stuff in hindsight. Well, let me qualify that! It is > not always so easy! Some people do it brilliantly. Ben C does it > better than anyone (at least to my ears). Thank you > I am not belittling the hindsight test as much as the use of the word > "hindsight" suggests. But a hindsight test is not a prediction test. > > And, crucially, the word "prediction" is not some piece of linguistic > magic that imprints its meaning on all mortal beings in the same way. I > say this because there will be a lot of people who think they know > exactly what is meant by the rules predict the behaviour and I am > just a little bit more skeptical. > > I am not trying to be awkward. I am this without effort most of the > time <g> It is good to try to have an intuitive understanding of why the rules are the way they are. There is some kind of rationale for most of it and if you can figure it out there's much more chance you can implement it correctly as a programmer or find the simplest ways to get the rendering effects you want as an author/designer.