J
Jonathan N. Little
Marc wrote:
look up CSS property 'float'
look up CSS property 'float'
M
Michael Winter
On 13/01/2006 21:43, cwdjrxyz wrote:
[Around 6KB of needlessly quoted text]
Please learn how to post; trim quotes.
[snip]
That's quite a bad example, on several fronts. Probably the worst, of
course, is...
[snip]
....which totally fails to act how a compliant server should. Not only
will it serve XHTML to a user agent that would (perhaps overwhelmingly)
prefer HTML, it would even serve XHTML to an agent that explicitly
forbade it.
May I ask what's the point of that large comment? Moreover, what
possessed you to even think of scripting an obnoxious prompt that would
be viewed by the majority of your users?
[snip]
Mike
[Around 6KB of needlessly quoted text]
Please learn how to post; trim quotes.
[snip]
That's quite a bad example, on several fronts. Probably the worst, of
course, is...
[snip]
....which totally fails to act how a compliant server should. Not only
will it serve XHTML to a user agent that would (perhaps overwhelmingly)
prefer HTML, it would even serve XHTML to an agent that explicitly
forbade it.
May I ask what's the point of that large comment? Moreover, what
possessed you to even think of scripting an obnoxious prompt that would
be viewed by the majority of your users?
[snip]
Mike
C
cwdjrxyz
Michael said:
I quite well know how to trim quotes, and if you examine some of my
other posts you will see that I often do. Since the poster asked a
variety of questions that I thought might be best covered by an
example, I wanted to leave all in to show what prompted my answer. Then
after reading my example code, the poster is of course free to ask
follow up questions if desired. Who in the world worries about 6 kb
anymore - at least not I. Today broadband pages with streaming media
files of over 50 MB are not uncommon, and even on 56K dialup a 10 kb
file is fast loading. Server disc space and bandwidth charges have now
become nearly dirt cheap and continue to become even cheaper(I only pay
about $US 10 a month on an annual basis for about 2 GB of disc space
and about 200 GB of monthly bandwidth) The only way I could come close
to using up my disc space and bandwith is to use a very large number of
streaming media files.
If someone does not wish to read the quote they are quite free not to
do so. In fact I am set up so you have to click on a quote message line
to display the quote at all.
"Bad example" is a value judgement taken alone, and is meaningless in a
technical example without technical specifics. Your follow up technical
specific concerns the mime2.php file. It is doing exactly what I want
it to do - namely serve application/xhtml+xml to any browser that
claims it will accept it at all. Some claim they would rather have
html, but I want to bypass that when at all possible. It turns out that
most recent common browsers that will accept the mentioned xhtml mime
type, even if they say they would prefer html, will in fact work just
fine using true xhtml on many properly written codes. I have written
over 100 pages with this approach, and find that it works fine on
recent Firefox, Mozilla, Netscape and Opera browsers. It serves html
4.01, as it should for IE6 and close relatives, such as the SBC/DSL DSL
browser. However, as with anything that is not yet being widely used
you have to be on the lookout for bugs, such as the CSS
background-color bug for Mozilla family browsers mentioned in a comment
in my posted code. You need to test your pages on several browsers, but
I know few persons who are so perfect that they do not have to check
html 4.01 on several browsers either. I suspect the fact that many
browsers respond that they will accept application/xhtml+xml, but
prefer html, is just to protect the browser vendors from complaints
caused by a few bugs that can turn up at this early stage. Many people
once would argue that one should not use CSS because it had many bugs,
as indeed it did in 4 era browsers. Today many posting here will jump
all over you if you do not use CSS. And of course CSS will not work on
all browsers, but now only a tiny percentage of very old browsers.
The point of the large comment is to complain that IE is out of step
with most other modern browsers and W3C standards. My little comment
may not help much, but if enough people complain about Microsoft's lack
of support of application/xhtml+xml there is a minute chance that they
might start to correct the situation within the next 5 to 10 years.The
comment will be seen only by those who look at the code, and not on
viewing the page.
The prompt is of course commented out and not used on the page. When
modifying the mime.php file, it is useful to trace what path is being
selected. Of course there may be some so dissatisfied with Microsoft's
lack of support of W3C standards that they may want to leave the prompt
on the page. I decided not to, for the reason that some, including
myself, may use the calendar generator page often, and the prompt soon
becomes tiresome.
The php calendar page posted will of course work if javascript is not
supported. Just turn off script on Firefox for example, and you should
still be able to use the page. The only thing that would not show, sans
script, is the mentioned prompt, if you used it, which I do not on my
example.
For those for whom the mention of true xhtml 1.1 causes a large
increase in blood pressure, they may use the html 4.01 strict page that
I posted. Of course javascript must be turned on for that. The
extensive calculations needed are far beyond the reach of plain html -
javascript, php, perl etc are needed. So far I have not had anyone
complain that the php page will not work on a common modern browser,
and if they did I would send them the URL for the 4.01 strict html page
at the URL I posted. Of course the page might not be suitable for some
handheld devices with a tiny screen that is too small to display a
calendar for a whole year. One likely would have to add an option to
allow display of single months to have any chance of being viewable on
a tiny screen, and even that might require better eyesight than many of
us have.
I would be happy to view the code for any of your pages written to work
on true xhtml 1.1. I am not interested in finding fault. At this early
stage every new approach to best using xhtml 1.1 and bugs that may
occur when using it helps. The more that contribute, the better. Actual
working page examples, with comments to point out how possible problems
are overcome, are much more useful than tons of verbiage and abstract
general discussions about the relative merits of this and that.
M
Marc
Jonathan said:
I know about float, I use it all the time, I just didn't think you could
use it like that.
Marc
S
Spartanicus
Marc said:
Any other usage ("CSS layouts" etc) is a nasty hack.
D
David Dorward
cwdjrxyz said:
Incorrect. It serves application/xhtml+xml to any browser that mentions that
mime type in its accept header - even if the mentioning is to explicitly
state that it does not accept it (i.e. with a quality value of zero).
What a great idea. Assume that you know what a browser supports better then
the browser itself. That's never going to cause a problem! said:
What background colour bug? I seem to recall some discussion on backgrounds
a while back, which came to the conclusion that XHTML was not HTML and thus
certain special cases which apply to HTML don't apply to XHTML - but I
don't remember the specifics right now.
M
Michael Winter
Then please be kind enough to do it in future.
Your posted was related to only the first question.
[snipped pointless drivel about bandwidth]
This is Usenet, not the Web. It is a simple courtesy to keep bandwidth
usage to a minimum and follow the preferred posting style of the group.
[snip]
I have no problem mentioning the in-line CSS declarations, the absolute
positioning, the pixel dimensions (and font size), the useless and
inaccurate META element, and the generally poor markup (the worst of
which is that block of text to the right). However, that wasn't the
point of your example, so I just hinted at the presence of other issues.
As both David and I have said, that isn't what it does at all.
Stop wanting that, then.
The BODY element is rendered just like any other block-level element,
and only extends to surround content that is in normal flow. As such,
the background colour will not be rendered across the entire viewport.
The HTML element is the document root, and setting a background colour
there will cause it to be rendered as you'd prefer.
Mozilla only states that it prefers XHTML so that resources that would
negotiate between, say, HTML and XHTML with MathML, would choose the
latter[1]. Opera ranks XHTML and HTML the same. I don't know off-hand
what Konqueror's and Safari's Accept header contains.
Irrespective of their reported preferences, all of these browsers do,
for some reason or another, prefer HTML. Mozilla cannot incrementally
render XHTML. Opera 7.x wouldn't execute scripts in XHTML documents.
Previous Konqueror versions, as I recall, didn't parse XHTML as XML.
[snip]
With a properly marked-up document, it won't matter that much if CSS is
not supported (or disabled); the document will be unstyled, but still
readable and in a logical order.
[snip]
And how exactly does that help the user (especially as they won't read
it, anyway)?
Microsoft should be left to implement XHTML properly in their own time.
Rushing their efforts will do far more harm than good.
[snip]
Mike
[1] <http://www.mozilla.org/docs/web-developer/faq.html#accept>
A
Alan J. Flavell
Blimey, *that* old chestnut again. Why *do* people insist on
reinventing the wheel, and then making it square? (or in this case
maybe triangular).
C
cwdjrxyz
Michael said:
I will post exactly how I think is best in the future. This group does
not have a moderrator, and if you do not like my posts, no one is
forcing you to read them.
A matter of opinion. However the poster is free to ask anything else he
or she wishes.
Yes I know this is archaic Usenet with multiple sources, slowness, and
far inferior to a modern BB where posts can nearly become as fast as
chat. It dates from a day when one had to very slowly download many
posts to read just a few of interest or configure a newsreader in great
detail to accept only certain posts. But the world moves on. I never
use an email agent or news reader on my computer. Rather I use domain
mail and email provided by my ISP, SBC/Yahoo DSL, which has very
effective filters and very good virus scan for attachments before even
allowing you to view them or copy them to computer. I find the new
Google access to groups very good, although it did have a few growing
pains. It arranges posts in order, so far as possible, and usually a
post you make appears almost at once, although of course it may take
considerable time to reach the many other branches of Usenet. I do not
need silly things such as a kill file, since that does not make posts
go away - it is somewhat like the ostrich who burries his head in the
sand. It might be useful for those who still insist on downloading
Usenet posts, in order to reduce the number of flame war posts, etc
downloaded. In fact I find Usenet so archaic and quaint in the old
technology it uses, that I only use 3 groups on it - on subjects of
interest that are not covered elsewhere. Since my computer is on all of
the time on DSL I can easily pop into Usenet at Google while my
computer is working on other things, such as processing video files.
You seem to miss the point that there are about 60000 calendars and
each has to be custom calculated including custom CSS for each.The most
direct method is to calculate using the inline declarations. This is
just as valid as CSS in the head or in an external file. The beauty of
CSS is that you can use a mix of CSS at 3 different levels as is most
convenient. If one were downloading only one calendar, rather than one
of 60000 that had to be calculated, then much more of the CSS would be
convenient to put in the head or an external file. I also remind you
that the CSS does validate on the W3C CSS validator. The absolute
positioning, pixel dimensions, and font size are quite necessary to
control the calculation of the calendar in a reasonable manner to fit a
desired field. The calendar turns out just the way I want it to be
displayed on a screen from about 560 px wide and up. This will make the
calander viewable on nearly all modern computer screen settings
including the 560 px width old MSNTV browser without right scrolling.
If someone uses an older narrow screen setting, they can easily right
scroll to read the text which is just an extra and not needed to view
the calendar. The text is about as large as it can be to display the
full calendar down to a 560 px wide screen. Support of under 560 pixel
likely would not be practical, because the text would have to be so
small in the calendar.
Sorry, I have seen numerous publications concerning what the browser
might prefer to accept, what it will accept, etc. I tried several
methods considering this in early attempts to use correct xhtml 1.1
served correctly. I find that most of these just end up in serving html
instead of xhtml. However I took the bold step of using the xhtml path
for any browser that mentioned it. In theory there could, and may be,
some of the many thousand browsers that would mention
application/xhtml+xml and yet not handle it. However I found this not
to be the case for the browsers that make up by far the bulk of
browsers now being used. This includes recent versions of Firefox,
Opera, Netscape, Mozilla, IE6 and close relatives. I also had reports
that two other recent browsers also worked well. I am satasfied with
this coverage. It is far better than my bank, credit card company, etc
have. If you find a recent, often used browser for which my method
takes the wrong path, let me know. As I mentioned earlier, I posted a
URL for an old html 4.01 strict page that would work in that case.
Call it a bug, or whatever you wish, but the fact is that if you write
an html page and view it on IE6, Mozilla family, or Opera browsers, the
background color extends to the bottom of the screen if the content
does not fill the whole screen, if you declare the background-color in
the body section of the CSS style sheet. However if you convert the
page to proper xhtml 1.1 and serve properly, IE6(gets html strict
instead of xhtml) and Opera still extend the background color to the
bottom of the screen for a non-full screen, while the Mozilla family
browsers stop the background color at the end of the content displayed
on the screen, with bright white instead of black to the bottom of the
screen in my example. I perhaps can think of better names than bug for
this problem, which are not suited for this group
.I do not have Konqueror or Safari browsers. However I did receive
screen shots on Safari and(I think) Konqueror, browsers that showed
that they worked on an xhtml page served as .xtml which will not work
on browsers such as IE6 that can not handle application/xhtml+xml.
It would be nice if Konqueror supports correct xhtml. However this
browser is so little use by anyone I know - I have never seen a
Konqueror browser - that I would not be too concerned if it does not
support xhtml - after all neither does IE6.
The problem is that Microsoft did nearly no browser development for a
few years and let the IE6 become stale. However the Mozilla family
browsers, Opera, and others continued browser development. Then Firefox
started to catch on. Microsoft then started some browser development
recently, but they have a lot of catch-up to do. Apparently the IE7 is
mainly a bug fix and inclusion of some features that other browsers
such as Firefox and Opera introduced, but we will not know for sure
untill the official release of a stable version of IE7.
I am still hoping to see some of your pages written in xhtml 1.1 and
served as such.
C
cwdjrxyz
David said:
I answered about the same as the above in a response to Michael Winter.
To avoid extensive duplication, I will not repeat it here.
The above also is covered in my long response to Michael Winter
C
cwdjrxyz
Alan said:
I covered about the same as the above in a long response to Michael
Winter. Thus I will not repeat it here.
M
Marc
Spartanicus said:
Are you saying you don't approve of a layout with, for example with 2
<div>s where one is floated to put it along side the other?
Marc
D
David Dorward
cwdjrxyz said:
Oh yes, the modern BB ... with a single point of failure and inflexible
interface that usually lacks spell checking, the ability to resize the text
entry area, the speed of skimming through posts in many channels, etc etc.
It might not make them go away, but it does hide them. That way I'm not
tempted to respond to moronic trolls. On the subject of which ... *plonk*
Why? Doing so wouldn't bring any benefit.
S
Spartanicus
Marc said:
It's a nasty hack, drawbacks:
a) It was never intended to be used as such, consequently usage other
than it's intended usage is fraught with issues that many authors
struggle with.
b) The CSS float rules are preposterously complex, this has resulted in
numerous browser float bugs, resulting in even more author confusion.
M
Marc
Spartanicus said:
So what would you recommend as an alternative? Absolute/Relative
Positioning? Tables?
Marc
M
Marc
David said:
David, I'd appreciate your view on my original post.
Thanks,
Marc
D
David Dorward
Marc said:
As I said: <
If you serve XHTML as text/html then it is treated as malformed HTML,
and there is no point in using it. (OTOH, if you serve it as
application/xhtml+xml, then 90% of your audience won't get it, and
there is still no point in using it).
So HTML 4.01 Strict.
(Generally at least. There are some exceptions, usually involving MathML,
where XHTML could be useful - but those aren't all that common).
S
Spartanicus
Marc said:
A proper answer to that question is too big a topic for usenet.
M
Marc
What therefore would you count as its intended use? Just to align
images within a body of text?
Oh I'm sure you can try to formulate a response. I'm fairly literate in
CSS so you don't need to explain the methodology, I'm just interested in
your opinion as to what is the best alternative to floating <div>s.
Marc
images within a body of text?
Oh I'm sure you can try to formulate a response. I'm fairly literate in
CSS so you don't need to explain the methodology, I'm just interested in
your opinion as to what is the best alternative to floating <div>s.
Marc
S
Spartanicus
Marc said:
Inline content flowing beside and beneath a rectangular object that is
right or left aligned.
A comprehensively answer really is far too big a topic for the
transitory medium that is usenet. I'm not aware of a web resource that
explains all of it properly.
IIRC there was an url posted here not long ago pointing to an article on
floats written by a well known Mozilla guy. Someone here may remember it
and be able to point you to it, or a trawl through the group's archive
may help (I didn't read the article, but IIRC "float" was in the title
of the group's post).