Posted by cwdjrxyz on 10/13/21 11:37

Michael Winter wrote:
> On 16/01/2006 03:10, cwdjrxyz wrote:
>
> > Michael Winter wrote:
> >
> >> On 13/01/2006 21:43, cwdjrxyz wrote:
> >>
> >> [Around 6KB of needlessly quoted text]
> >>
> >> Please learn how to post; trim quotes.
> >
> > I quite well know how to trim quotes [...]
>
> Then please be kind enough to do it in future.

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.

> > Since the poster asked a variety of questions that I thought might be
> > best covered by an example [...]
>
> Your posted was related to only the first question.

A matter of opinion. However the poster is free to ask anything else he
or she wishes.

> [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.

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.


> > "Bad example" is a value judgement taken alone, and is meaningless in a
> > technical example without technical specifics.
>
> 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.
>

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.

> > 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.
>
> As both David and I have said, that isn't what it does at all.
>
> > Some claim they would rather have html, but I want to bypass that
> > when at all possible.
>
> Stop wanting that, then

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.

> > [...] bugs, such as the CSS background-color bug for Mozilla family
> > browsers [...]
>
> 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.

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 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.
>
> 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.

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.

> 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.

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.

> [snip]
>
> > And of course CSS will not work on all browsers, but now only a tiny
> > percentage of very old browsers.
>
> 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]
>
> > The point of the large comment is to complain that IE is out of step
> > with most other modern browsers and W3C standards.
>
> And how exactly does that help the user (especially as they won't read
> it, anyway)?

> > My little comment may not help much, but if enough people complain
> > about Microsoft's lack of support of application/xhtml+xml [...]
>
> Microsoft should be left to implement XHTML properly in their own time.
> Rushing their efforts will do far more harm than good.

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.

[Back to original message]