473,320 Members | 1,939 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

display:block on form elements

Hello.

In trying to get an anchor element to stylistically match an input or button
element, I find that the button and input cannot be styled according to the
2.1 CSS spec. For example, I expected this ruleset:

..but {
display: block; background-color: red;
font-size: 14px; text-decoration: none; line-height: 16px;
width: auto; height: 16px; padding: 0; margin: 0;
text-align: center; cursor: pointer;
border-width: 4px; border-style: solid;
border-color: #FFCCCC #990000 #990000 #FFCCCC;
}

to give the same appearance to A, INPUT and BUTTON elements with
class="but", but it does not on IE 5-6, Firefox or Opera 9. Opera 7.5
rendered height correctly, but Opera 9 renders INPUT and BUTTON as badly,
sizewise, as Firefox and IE.

Am I missing something, or is this some kind of non-compliance conspiracy?

Example: http://www.hpaa.com/css1/temp.htm

Dave
Jul 6 '06 #1
25 2436
"Dave" <no********@no.wherewrote:
>In trying to get an anchor element to stylistically match an input or button
element, I find that the button and input cannot be styled according to the
2.1 CSS spec. For example, I expected this ruleset:

.but {
display: block; background-color: red;
font-size: 14px; text-decoration: none; line-height: 16px;
width: auto; height: 16px; padding: 0; margin: 0;
text-align: center; cursor: pointer;
border-width: 4px; border-style: solid;
border-color: #FFCCCC #990000 #990000 #FFCCCC;
}

to give the same appearance to A, INPUT and BUTTON elements with
class="but", but it does not on IE 5-6, Firefox or Opera 9. Opera 7.5
rendered height correctly, but Opera 9 renders INPUT and BUTTON as badly,
sizewise, as Firefox and IE.

Am I missing something, or is this some kind of non-compliance conspiracy?

Example: http://www.hpaa.com/css1/temp.htm
Styling UI elements like form elements is rather questionable, they
should be immediately identifiable by a user. I'd say that is more
important than such elements blending in with a page design.

Browsers may or may not allow form elements to be styled, this can be
enforced (Mac browsers) or sometimes it's available as a user
configurable setting (Opera).

Given that you cannot rely on form elements being styleable, attempting
to make non form elements look like form elements is prone to failure
since you have no idea what a form element will look like on a given
client system

--
Spartanicus
Jul 6 '06 #2

"Spartanicus" <in*****@invalid.invalidwrote in message
news:i8********************************@4ax.com...
Styling UI elements like form elements is rather questionable, they
should be immediately identifiable by a user. I'd say that is more
important than such elements blending in with a page design.
Web designers are quite capable of making form elements identifiable or
non-identifiable as they see fit. Are you saying browser developers should
insist that this be done only with images?

I am revising a page that currently uses 3 images as buttons for submit
("Post message"), reset ("Clear all"), and a "Cancel" anchor link to return
to the previous page. In the 8 years this page has been in existence, no one
has failed to identify the purpose of these buttons. Now I'm trying to
simplify the page, using CSS instead of images. Not having these buttons
look the same will confuse the user, so I'll have to continue using images,
adding to bandwidth and development time. How can you possibly consider this
to be a good thing?
Given that you cannot rely on form elements being styleable, attempting
to make non form elements look like form elements is prone to failure
since you have no idea what a form element will look like on a given
client system
CSS is about simplifying control over presentation. Consistent application
of rules is a must. Arbitrarily altering application of the rules for
certain elements is just plain wrong. The identification of form elements is
the concern of the website owner, not the browser developer.

It's funny when folks claim standard HTML presentation is "immediately
identifiable" to newbie internet users (I recall someone looking at a
standard web form for the first time and asking "submit to what?"). It's
depressing when they imply that web designers need to be constrained by some
'higher authority' that determines what is 'correct' presentation.

BTW, the buttons can be made to match sizewise across 3 browsers, but, like
the 'good ol days', just not using accepted standards. Example added to
http://www.hpaa.com/css1/temp.htm.

Dave
Jul 6 '06 #3
On Thu, 6 Jul 2006, Dave wrote:
CSS is about simplifying control over presentation. Consistent
application of rules is a must.
Just think about it in those terms. Users spend most of their time on
other sites. They get to know what the different web elements look
like, to recognise them when they see them again, and know what to do
with them without having to be told over again.

If you succeed in making them look like something else, they're liable
to get confused, and will then need distracting instructions on how to
use something that, if only they had recognised it as something they'd
used before, they'd have known what it was for.

So yes, your reference to consistency was correct, but your conclusion
was less appropriate. These are key elements of a web site, they
aren't just visual fluff, it's important that the user recognises them
when they see them (unless you're engaged in phishing or other
disreputable activities, when the whole purpose of the exercise is to
confuse the victim into doing something that they wouldn't have done
if they'd been able to recognise what they were dealing with).
It's funny when folks claim standard HTML presentation is
"immediately identifiable" to newbie internet users (I recall
someone looking at a standard web form for the first time and asking
"submit to what?").
From which you could have concluded that these first steps with a web
browser are very important, and anything that authors can do to
enhance recognition of the key elements whenever they are encountered
(i.e not trying to dress them up as something else) is a benefit to
the user.

Instead of complaining that some browsers are failing to comply with
your attempts to dress up your form elements, you'd do better to
concentrate on their usability, which, as a genearal rule, means not
trying to camouflage them in the first place.
It's depressing when they imply that web designers need to be
constrained by some 'higher authority' that determines what is
'correct' presentation.
The final "higher authority" in web design is the user. Even if many
of those who commission web sites think that it's *their* call, the
web still does what it does - those who insist on defeating it are
liable to get their just rewards.

IMHO and YMMV.
Jul 6 '06 #4
"Dave" <no********@no.wherewrote:
>Styling UI elements like form elements is rather questionable, they
should be immediately identifiable by a user. I'd say that is more
important than such elements blending in with a page design.

Web designers are quite capable of making form elements identifiable or
non-identifiable as they see fit.
Indeed, and I'm saying that authors shouldn't obscure them by attempting
to style them.
>Are you saying browser developers should
insist that this be done only with images?
I'm saying that obscuring form elements is a bad idea regardless of how
you do it.
>I am revising a page that currently uses 3 images as buttons for submit
("Post message"), reset ("Clear all"), and a "Cancel" anchor link to return
to the previous page. In the 8 years this page has been in existence, no one
has failed to identify the purpose of these buttons.
You don't know that. It would be most unusual for a user to bother
complaining about such things.
>Given that you cannot rely on form elements being styleable, attempting
to make non form elements look like form elements is prone to failure
since you have no idea what a form element will look like on a given
client system

CSS is about simplifying control over presentation. Consistent application
of rules is a must. Arbitrarily altering application of the rules for
certain elements is just plain wrong.
Nonsense, you seem to have confused web authoring with DTP. Varying
presentations on client systems are a key aspect of web authoring, and
CSS purposely contributes to that.
>The identification of form elements is
the concern of the website owner, not the browser developer.
The real issue here has nothing to do with browser developers. What
should concern web authors is the usability of their site.
>It's funny when folks claim standard HTML presentation is "immediately
identifiable" to newbie internet users
Not "newbie" users, just users. Form elements that look different on
different web sites are a significant obstacle to usability.

--
Spartanicus
Jul 6 '06 #5
"Alan J. Flavell" <fl*****@physics.gla.ac.ukwrote in message
news:Pi******************************@ppepc20.ph.g la.ac.uk...

Truly bizarre. I point out that browsers are not fully supporting the CSS
spec and I get excuses that the problem might somehow benefit an
archetypical user who gets confused when a form button isn't a gray
rectangle, along with the implication that an expectation of this support
implies that a designer must be camouflaging function and (gasp) maybe even
engaging in suspicious behavior. Surely you must be an inept developer or
industry obfuscator, and not just a pompously condescending lecturer? ;-)
CSS is about simplifying control over presentation. Consistent
application of rules is a must.

Just think about it in those terms. Users spend most of their time on
other sites. They get to know what the different web elements look
like, to recognise them when they see them again, and know what to do
with them without having to be told over again.

If you succeed in making them look like something else, they're liable
to get confused, and will then need distracting instructions on how to
use something that, if only they had recognised it as something they'd
used before, they'd have known what it was for.
They? You obviously consider yourself a non-user. Do you know any users, or
are they an abstraction, like "commoners?" Do "they" get confused when a
button isn't gray or perfectly rectangular? How do these idiots manage to
start their computers?
So yes, your reference to consistency was correct, but your conclusion
was less appropriate. These are key elements of a web site, they
I made no conclusion besides it being wrong to give form elements
non-standard style properties. My last statement was lacking a word.
Corrected: "The user's identification of form elements is the concern of the
website owner, not the browser developer."
aren't just visual fluff, it's important that the user recognises them
when they see them
You are arguing this with whom?
(unless you're engaged in phishing or other
disreputable activities, when the whole purpose of the exercise is to
confuse the victim into doing something that they wouldn't have done
if they'd been able to recognise what they were dealing with).
And your point relative to my posts is...? Are you saying that flawed
support of CSS helps inhibit obfuscation of form elements?
Instead of complaining that some browsers are failing to comply with
your attempts to dress up your form elements, you'd do better to
concentrate on their usability, which, as a genearal rule, means not
trying to camouflage them in the first place.
Style is about 'dressing up' elements. Form elements are not exempt, nor
does it follow that the dressing inhibits usability. Why I would "do better"
doing what I do "instead of" complaining is beyond my comprehension.
The final "higher authority" in web design is the user.
Ah, the profundity of academics. Too bad you're semantically incorrect. The
user, AKA vistor, AKA consumer, is the arbiter, not the authority.

My assertion: Current browsers do not support styling of INPUT and BUTTON
elements in accordance with current standards. More harm than good comes
from flawed standards support. Browsers should support styling of INPUT and
BUTTON elements according to current standards.

I also posed a question which could be restated as: why did Opera and
Firefox echo an MSIE flaw, assuring mutual non-compliance with the CSS 2.1
spec?

Dave
Jul 6 '06 #6
In message <eU********************@newssvr13.news.prodigy.com >, Dave
<no********@no.wherewrites
>CSS is about simplifying control over presentation.
No: CSS is not about control at all. It is abut suggestion; and its
suggestions may be ignored.
--
Andy Mabbett
Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>

Free Our Data: <http://www.freeourdata.org.uk>
Jul 8 '06 #7

"Andy Mabbett" <us**********@pigsonthewing.org.ukwrote in message
news:8v**************@pigsonthewing.org.uk...
No: CSS is not about control at all. It is abut suggestion; and its
suggestions may be ignored.
Sigh. Yet another semantical duffer with an ideological agenda?

Call it what you will, if browser developers ignore the standard then even
suggestion becomes pointless, because the suggestion has lost its meaning.
The browser is the implementer of the web designer's instructions. The
standard allows the viewer to ignore or modify those instructions, but the
basic purpose of the standard is to ensure that the viewer CAN see the page
rendered in accordance with those instructions.

So, yes, in one sense it certainly is about control. Most people choose to
view web pages as the designer intended them to be seen. Adherence to the
standard benefits both the designer and the viewer.

Dave
Jul 8 '06 #8
On Sat, 8 Jul 2006, Dave wrote:
"Andy Mabbett" <us**********@pigsonthewing.org.ukwrote in message
news:8v**************@pigsonthewing.org.uk...
No: CSS is not about control at all. It is abut suggestion; and
its suggestions may be ignored.

Sigh. Yet another semantical duffer with an ideological agenda?
Whether you call it a "suggestion" or a "proposal" may indeed be a
feature of your ideological agenda; but, whichever way you parse it,
CSS *is* optional *by design*, and the user gets the last word,
whether by applying a user stylesheet (with !important) or by ignoring
your CSS entirely.

So calling it "control" is, from the point of view of an author,
not only an exaggeration in practical terms, but a misunderstanding in
terms of underlying principles.
Call it what you will, if browser developers ignore the standard
then even suggestion becomes pointless, because the suggestion has
lost its meaning.
Can you remind us of which statement that was intended to refute?
Most of us here support conformance with the specifications, I think
it's fair to say.
The browser is the implementer of the web designer's instructions.
As cascaded with any other relevant options, indeed.
The standard allows the viewer to ignore or modify those
instructions, but the basic purpose of the standard is to ensure
that the viewer CAN see the page rendered in accordance with those
instructions.
"CAN see the page"? When an author succeeds in imposing a font size
that is too small to be read by a sight-impaired user, something has
failed, wouldn't you agree?

So, either authors must use size units which scale with the users'
needs (that's what em units and percentages are about), or users must
override the author's proposals with their own requirements. Both of
these scenarios are covered by the published specifications. If you
think about it logically, the situations where authors believe they
have the most control (i.e by enforcing px or pt sizing) are in
reality those where their "control" most often has to be taken away
from them in the interests of the user.
So, yes, in one sense it certainly is about control. Most people
choose to view web pages as the designer intended them to be seen
I "intend" my pages to be seen as the reader wants or needs them. I
reckon that's a win-win situation.
Adherence to the standard benefits both the designer and the viewer.
Using the specifications in accordance with good-practice (such as
WAI) rates to benefit them even more.

Jul 8 '06 #9
"Dave" <no********@no.wherewrote:
>No: CSS is not about control at all. It is abut suggestion; and its
suggestions may be ignored.

Sigh. Yet another semantical duffer with an ideological agenda?

Call it what you will, if browser developers ignore the standard then even
suggestion becomes pointless, because the suggestion has lost its meaning.
The browser is the implementer of the web designer's instructions. The
standard allows the viewer to ignore or modify those instructions, but the
basic purpose of the standard is to ensure that the viewer CAN see the page
rendered in accordance with those instructions.

So, yes, in one sense it certainly is about control. Most people choose to
view web pages as the designer intended them to be seen. Adherence to the
standard benefits both the designer and the viewer.
Quote from http://www.w3.org/TR/CSS21/conform.html#conformance

"CSS 2.1 does not define which properties apply to form controls and
frames, or how CSS can be used to style them. User agents may apply CSS
properties to these elements. Authors are recommended to treat such
support as experimental. A future level of CSS may specify this
further."

--
Spartanicus
Jul 8 '06 #10

"Alan J. Flavell" <fl*****@physics.gla.ac.ukwrote in message
news:Pi*******************************@ppepc20.ph. gla.ac.uk...
On Sat, 8 Jul 2006, Dave wrote:
"Andy Mabbett" <us**********@pigsonthewing.org.ukwrote in message
news:8v**************@pigsonthewing.org.uk...
No: CSS is not about control at all. It is abut suggestion; and
its suggestions may be ignored.
Sigh. Yet another semantical duffer with an ideological agenda?

Whether you call it a "suggestion" or a "proposal" may indeed be a
feature of your ideological agenda; but, whichever way you parse it,
CSS *is* optional *by design*, and the user gets the last word,
whether by applying a user stylesheet (with !important) or by ignoring
your CSS entirely.
Hmm, thought I said that, basically.
So calling it "control" is, from the point of view of an author,
not only an exaggeration in practical terms, but a misunderstanding in
terms of underlying principles.
IMHO, horse kaka.
Call it what you will, if browser developers ignore the standard
then even suggestion becomes pointless, because the suggestion has
lost its meaning.

Can you remind us of which statement that was intended to refute?
Most of us here support conformance with the specifications,
Admonition to refrain from complaint implies otherwise.
The browser is the implementer of the web designer's instructions.

As cascaded with any other relevant options, indeed.
Very repetitious. (sung to a Stevie Wonder melody)
The standard allows the viewer to ignore or modify those
instructions, but the basic purpose of the standard is to ensure
that the viewer CAN see the page rendered in accordance with those
instructions.

"CAN see the page"? When an author succeeds in imposing a font size
that is too small to be read by a sight-impaired user, something has
failed, wouldn't you agree?
There's a difference between "see" and "read." If it's your view that the
reader should not be able to see the page as intended by the author if the
page fails to comply with your definition of good design practice...well,
you'd have done well in Stalinist Russia. I agree that if your hypothetical
web page is not intended only for readers with good eyesight then the author
has failed their task. However, authors do have the right to be inept, and
may sometimes be required to do things they don't approve of. Perhaps they
will learn and improve. Perhaps market forces will move them to a different
profession. And perhaps browsers will make it easy to zoom an entire page,
including containers and graphics, and scroll about it, basically doing
electronically what is commonly done with a magnifying glass and printed
material. This would be in addition to the option to resize the base font,
and seems a much better approach to me than simply resizing pixel-sized
type, especially in cases where a graphic conveys important information.
(Upsize type on the NYTimes website using Firefox 1.5 for a good example of
how resizing only the pixel-sized type can be counter-productive.)
So, either authors must use size units which scale with the users'
needs (that's what em units and percentages are about), or users must
I was promoting emsizing 9 years ago.
override the author's proposals with their own requirements. Both of
these scenarios are covered by the published specifications. If you
think about it logically, the situations where authors believe they
have the most control (i.e by enforcing px or pt sizing) are in
reality those where their "control" most often has to be taken away
from them in the interests of the user.
As long as that control is taken by the reader, that's as it should be. If
taken away by social engineers in the 'public interest', it's not.
So, yes, in one sense it certainly is about control. Most people
choose to view web pages as the designer intended them to be seen

I "intend" my pages to be seen as the reader wants or needs them. I
reckon that's a win-win situation.
If your readers understand what you've presented and are pleased with how
you presented it, you're doing a fine job.
Adherence to the standard benefits both the designer and the viewer.

Using the specifications in accordance with good-practice (such as
WAI) rates to benefit them even more.
The WAI guidelines look very sensible. Thanks for the reference.

Dave




Jul 9 '06 #11

"Spartanicus" <in*****@invalid.invalidwrote in message
news:m0********************************@4ax.com...
Quote from http://www.w3.org/TR/CSS21/conform.html#conformance

"CSS 2.1 does not define which properties apply to form controls and
frames, or how CSS can be used to style them. User agents may apply CSS
properties to these elements. Authors are recommended to treat such
support as experimental. A future level of CSS may specify this
further."
Thank you, Spartanicus! I had looked for such a disclaimer but clearly not
with due diligence.

Dave
Jul 9 '06 #12
In message <QY*******************@newssvr12.news.prodigy.com> , Dave
<no********@no.wherewrites
>"Andy Mabbett" <us**********@pigsonthewing.org.ukwrote in message
news:8v**************@pigsonthewing.org.uk...
>No: CSS is not about control at all. It is abut suggestion; and its
suggestions may be ignored.

Sigh. Yet another semantical duffer with an ideological agenda?
No.

Do you have anything to say which isn't either insulting, wrong, or
both?
--
Andy Mabbett
Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>

Free Our Data: <http://www.freeourdata.org.uk>
Jul 9 '06 #13

"Andy Mabbett" <us**********@pigsonthewing.org.ukwrote in message
news:YL**************@pigsonthewing.org.uk...
Sigh. Yet another semantical duffer with an ideological agenda?

No.
Then I apologize for the suspicion.
Do you have anything to say which isn't either insulting, wrong, or
both?
I said a number of things that were not wrong or insulting, e.g.: the user
is an arbiter, not an authority. Whether CSS is about control is arguable,
but in a practical sense control is exercised. How a CSS rule constitutes a
suggestion - "a process by which an idea is induced in or adopted by another
without argument, command, or coercion" - eludes me. On the other hand,
control - the "ability to manage or direct" - seems reasonably apt and does
not preclude directions being superseded or ignored. Perhaps this is a case
where words mean exactly what you want them to, nothing more, nothing less.
Hopefully we can agree "CSS provides a means to specify how elements should
be rendered" and leave it at that.

Dave

Jul 10 '06 #14

"Andy Mabbett" <us**********@pigsonthewing.org.ukwrote in message
news:YL**************@pigsonthewing.org.uk...
No: CSS is not about control at all. It is abut suggestion; and its
suggestions may be ignored.
Quote from http://www.w3.org/TR/html401/intro/intro.html#h-2.3.5

"Style sheets simplify HTML markup and largely relieve HTML of the
responsibilities of presentation. They give both authors and users control
over the presentation of documents -- font information, alignment, colors,
etc."
Jul 10 '06 #15
On Mon, 10 Jul 2006, Dave wrote:
Quote from http://www.w3.org/TR/html401/intro/intro.html#h-2.3.5

"Style sheets simplify HTML markup and largely relieve HTML of the
responsibilities of presentation. They give both authors and users
control over the presentation of documents
That's someone at the W3C who's got their marketing hat on, it seems.

The reality is different, even if CSS wasn't meant to be optional by
design, as we can see by some examples of what you have cited:
-- font information,
Specifying a font name which the reader does not possess is certainly
not going to achieve any "control", right? (There have been
proprietary schemes for downloadable fonts, but they are not
officially part of current CSS, and they certainly are not implemented
in most browsers).

Some browsers (lynx, elinks, w3m...[1]) use a terminal font, and
aren't interested in what the author specifies. The same can be said
for the speaking browsers, really (the fact that most of them also
have a visual display doesn't really help, for example if you are
blind).
colors, etc."
"Colors" make little difference to a monochrome display (my
late-lamented Psion 5 for example, which had a web browser on it), and
certainly not on a speaking browser.

* When the ISP marketing speak says "unlimited downloads" it doesn't
mean you can download at line speed all day, every day. It may mean
that it costs no more to keep downloading, but don't be surprised if
the effective download speed goes down and down, the more you
download.

* When the supermarket marketing speak says "get one free", it doesn't
really mean it's free, it means you can buy two for the price of one,
i.e if you buy two, you get them half-price.

* And when the W3C marketing speak says "control", it doesn't really
mean you can guarantee a specific appearance on all browsers. Quite
the contrary: the whole aim of the original WWW was to present the
same content to vastly different presentation situations. That
principle hasn't changed: the actual presentation situations are quite
unlike what we originally had (early graphics displays, IBM 3270
terminals, DEC VT102 displays...), but they still represent a wide
diversity of presentation situations, for which the aim of achieving
identical visual results is just plain silly.

You already know this, but you still seem to be somewhat in denial.

regards

[1] If you think that browsers which use monospaced terminal fonts are
of no use to anybody, you might want to ask yourself why Lynx is still
being developed, and at least two other browsers of that kind (eLinks,
w3m) have emerged in relatively recent times. There must be a reason.

--

If the crash doesn't occur immediately, the [development] cycle is broken,
and the result is called a release. -- detha, in the monastery.
Jul 10 '06 #16

"Dave" <no********@no.wherewrote in message
news:wD*******************@newssvr27.news.prodigy. net...
>
"Spartanicus" <in*****@invalid.invalidwrote in message
news:m0********************************@4ax.com...
>Quote from http://www.w3.org/TR/CSS21/conform.html#conformance

"CSS 2.1 does not define which properties apply to form controls and
frames, or how CSS can be used to style them. User agents may apply CSS
properties to these elements. Authors are recommended to treat such
support as experimental. A future level of CSS may specify this
further."

Thank you, Spartanicus! I had looked for such a disclaimer but clearly not
with due diligence.
Out of interest, does this disclaimer appear in CSS 2.0?

Martin
Jul 10 '06 #17

Dave wrote:
"Style sheets simplify HTML markup and largely relieve HTML of the
responsibilities of presentation. They give both authors and users control
over the presentation of documents -- font information, alignment, colors,
etc."
I'd like to see CSS "control" font size and colour on a single font
single line of text LCD display.

It can "suggest" all it likes, but browser implementation (hardware and
software) _always_ wins.

Jul 10 '06 #18
"Martin Eyles" <ma**********@NOSPAMbytronic.comwrote:
>>Quote from http://www.w3.org/TR/CSS21/conform.html#conformance

"CSS 2.1 does not define which properties apply to form controls and
frames, or how CSS can be used to style them. User agents may apply CSS
properties to these elements. Authors are recommended to treat such
support as experimental. A future level of CSS may specify this
further."

Thank you, Spartanicus! I had looked for such a disclaimer but clearly not
with due diligence.

Out of interest, does this disclaimer appear in CSS 2.0?
2.0 is only of historical relevance.

From http://www.w3.org/TR/2005/WD-CSS21-2.../about.html#q1
"Implementations may refer to CSS2 for the definitions of features that
have been removed, but for other features CSS 2.1 is the normative
reference."

This text was changed in the current 2.1 draft due to pressure from
other working groups, but it is correct in this context.

--
Spartanicus
Jul 10 '06 #19

"Alan J. Flavell" <fl*****@physics.gla.ac.ukwrote in message
news:Pi*******************************@ppepc20.ph. gla.ac.uk...
You already know this, but you still seem to be somewhat in denial.
Denial of what? It's obvious "control" doesn't really mean you can guarantee
a specific appearance on all browsers. I don't expect to be able to control
rendering on non-CSS-supporting browsers, or when a viewer doesn't want to
view my content as I want to present it. And I understand that my ideal font
might not be available. But when I browse the web I am perfectly happy to
allow the authors of the pages I visit to control the rendering of their
content, because I want to see it as they have labored to present it to me.
If I don't like what I see I can exert my own control (which, as you know,
trumps the author's) but until I do so, the author has controlled, to some
degree, the presentation of their content. If allowing author control of
presentation were not the norm, there would not be much need for CSS.
...the whole aim of the original WWW was to present the
same content to vastly different presentation situations.
Really? I seem to recall the original purpose of the WWW was to link a
variety of resources for easy access (Gopher was a real pain). It was to be
"...a global hypertext space...in which any network-accessible information
could be refered to by a single 'Universal Document Identifier'...a common
information space in which we communicate by sharing information." But those
are just the words of Tim Berners-Lee. What does he know, eh?

It seems we can argue this til the cows explode from lack of milking and
you'll still not see the trees in the forest, so to speak. (Or, at least,
you'll not admit to seeing them.)

Dave
Jul 10 '06 #20
"Dave" <no********@no.wherewrites:
Denial of what? It's obvious "control" doesn't really mean you can guarantee
a specific appearance on all browsers.
Obvious to most of us, yes.

Unfortunately there's a very vocal group of people who say and "control"
and mean precisely that - and start whining about "luddites" who have a
"plain text agenda" when someone points out that such a precise level of
control simply isn't technically feasible for a document that's viewable
in an infinite variety of viewing conditions.

As a result, many regulars here have become a bit touchy about the word,
and try to stress the reality that CSS is essentially just a suggestion,
albeit one that's accepted without a second thought in most cases.

In other words, the word "control" has a history in this group, and because
of that history it has meaning here beyond its strict dictionary definition.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Jul 10 '06 #21

"Sherm Pendley" <sh***@Sherm-Pendleys-Computer.localwrote in message
news:m2************@Sherm-Pendleys-Computer.local...
Unfortunately there's a very vocal group of people who say and "control"
and mean precisely that - and start whining about "luddites" who have a
"plain text agenda" when someone points out that such a precise level of
control simply isn't technically feasible for a document that's viewable
in an infinite variety of viewing conditions.

As a result, many regulars here have become a bit touchy about the word,
and try to stress the reality that CSS is essentially just a suggestion,
albeit one that's accepted without a second thought in most cases.

In other words, the word "control" has a history in this group, and
because
of that history it has meaning here beyond its strict dictionary
definition.

I see. So anyone who uses the word "control" is subject to semantical
harangues until they accept a narrowed definition and agree that CSS is just
a suggestion, which it most certainly is not. I can see why such 'regulars'
want to narrow the meaning of control, lest the adjective form be rightly
applied to themselves.

Dave


Jul 10 '06 #22

"Spartanicus" <in*****@invalid.invalidwrote in message
news:7u********************************@4ax.com...
"Martin Eyles" <ma**********@NOSPAMbytronic.comwrote:
>>>Quote from http://www.w3.org/TR/CSS21/conform.html#conformance

"CSS 2.1 does not define which properties apply to form controls and
frames, or how CSS can be used to style them. User agents may apply CSS
properties to these elements. Authors are recommended to treat such
support as experimental. A future level of CSS may specify this
further."

Thank you, Spartanicus! I had looked for such a disclaimer but clearly
not
with due diligence.

Out of interest, does this disclaimer appear in CSS 2.0?

2.0 is only of historical relevance.

From http://www.w3.org/TR/2005/WD-CSS21-2.../about.html#q1
"Implementations may refer to CSS2 for the definitions of features that
have been removed, but for other features CSS 2.1 is the normative
reference."

This text was changed in the current 2.1 draft due to pressure from
other working groups, but it is correct in this context.
I am aware of this, which is why I say "out of interest". I am generally
interested (despite lack of practical application) to know how crippled 2.1
is over 2.0. I seem to remember things like font downloading also being in
2.0 and not in 2.1, which I felt was a shame, as people have ended up
writing ways of using flash to do it instead, which is an ugly method.
Anyway, if you know of a link to a changelog or something, it would make
interesting reading.
Jul 11 '06 #23
Martin Eyles wrote:
I am generally
interested (despite lack of practical application) to know how crippled 2.1
is over 2.0. I seem to remember things like font downloading also being in
2.0 and not in 2.1, which I felt was a shame, as people have ended up
writing ways of using flash to do it instead, which is an ugly method.
Anyway, if you know of a link to a changelog or something, it would make
interesting reading.
CSS 2.1 has an "Appendix C. Changes":
<http://www.w3.org/TR/CSS21/changes.html>. I don't think it's so
difficult to find in the table of contents.

--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
Jul 11 '06 #24
"Martin Eyles" <ma**********@NOSPAMbytronic.comwrote:
>2.0 is only of historical relevance.

From http://www.w3.org/TR/2005/WD-CSS21-2.../about.html#q1
"Implementations may refer to CSS2 for the definitions of features that
have been removed, but for other features CSS 2.1 is the normative
reference."

This text was changed in the current 2.1 draft due to pressure from
other working groups, but it is correct in this context.

I am aware of this, which is why I say "out of interest". I am generally
interested (despite lack of practical application) to know how crippled 2.1
is over 2.0.
One of the flaws of 2.0 is that parts of it have never been implemented
by anyone. This made the spec difficult to use for authors who are
unaware of what is and what isn't implemented. This is one aspect that
2.1 addresses. CSS 2.1 isn't "crippled", it reflects reality much
better.
>I seem to remember things like font downloading also being in
2.0 and not in 2.1, which I felt was a shame, as people have ended up
writing ways of using flash to do it instead, which is an ugly method.
Font downloading is one of the never implemented features. Authors who
insist on trying to use something like this had to turn to other ways to
do this anyway. The font downloading feature in CSS 2.0 hasn't
disappeared, it has been moved to the CSS 3 proposals.

--
Spartanicus
Jul 11 '06 #25
On Tue, 11 Jul 2006, Martin Eyles wrote:
I seem to remember things like font downloading also being in 2.0
and not in 2.1, which I felt was a shame, as people have ended up
writing ways of using flash to do it instead, which is an ugly
method.
Downloaded fonts were implemented, in different ways, in MSIE (weft)
and in NN4.*, but both of them used proprietary software. I've seen
it asserted that the NN4.* method was also implemented in the Netscape
versions 6+ based on gecko, but, as they were not available in
Mozilla/Firefox browsers, I never really looked into the matter.

One of the big problems in practice with the use of downloaded fonts
is that authors insisted on using them - not for providing typographic
improvements to the characters that were coded in the HTML - but for
swapping those bona fide characters for some unrelated glyphs that the
author happened to want. The downloaded analogy of the old HTML/3.2
"font face=Webdings", one might say, or indeed the faux Latin fonts
such as one finds at certain minority-script sites, all of which are
bogus according to mainstream HTML specifications right back from
HTML/2.0. And will guarantee wrong results for those who don't have
font downloading enabled (of which, search engines form a not
unimportant part).

If the dynamic fonts had been used properly for their intended
purpose, then they would have fallen-back gracefully in situations
where the optional feature was unavailable.

Over and above this, MS rightly discerned that fonts were a potential
security exposure, and so, if IE is set for an appropriate level of
safety against untrusted Internet sites, then every use of weft fonts
is going to provoke a security alert.

There's a bit of related discussion on my page
http://ppewww.ph.gla.ac.uk/~flavell/...i18n-weft.html

h t h
Jul 11 '06 #26

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

7
by: Jeff Thies | last post by:
I'm trying to do a nav list using list items. Roughly this is putting links styled display: block and with a background color. In IE5 (windows, haven't tried Mac yet), adding the display:...
18
by: David Morris | last post by:
G'day. Is there a known "display:block;" problem in opera? In playing around trying to get some cross browser conformance, I either inadvertently or redundantly (depending on your perspective)...
2
by: Richard | last post by:
When using display:block in a list array, is there a way to give a bit of seperation between the actual displays? ul {display:block;} ul li {display:block;} <ul> <li>item 1</> <li>item...
6
by: Sandman | last post by:
I'm having some problem here... I have a javascript I've downloaded that goes through all PNG files and enables the transparency channel in them for IE5.5+ by converting them to SPAN layers with...
6
by: dee | last post by:
Here is a a list of my hyperlinks in my home page: <A class="theclass" href="Default.aspx">Home</A> <A class="theclass" href="Search.aspx">Search</A> <A class="theclass"...
2
by: ruby_bestcoder | last post by:
Hi Im having problem in firefox with display:none/block. I have essentially 3 li elements. In each element there are a few nested div:s. Clicking on one of the divs, makes another div to...
1
by: pastrami | last post by:
Hey guys, I was wondering if someone can check my css setup, for some reason my pictures are not coming out centered in FF but it is centered in IE. table#gallery { display:none;...
7
by: Janis | last post by:
I try to understand what could be the source of a problem with displaying and hiding rows of tables using display:block/none. I've read selfhtml but could not find any hint about that. Any...
3
by: WSPL5 | last post by:
I have a hidden span within a table column and I cannot unhide it using style.display='block' ?? Sample code <table> <tr> <td><input name="status" value=""></td><td><input type="button"...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.