I used to use browsershots.org to test cross-compatibility of my
websites, but it's down now and it looks like it's been that way
for at least a few months. Other services that I've found are all
free trials, is there a good permanently-free alternative like
Browsershots hiding somewhere? Or another instance of Browsershots
(since it's open-source)?
I only need screenshots of static webpages in a range of browsers.
None of this interactive testing stuff that the commercial
services seem to be pushing.
On 3 Mar 2025 13:17:33 +1000, Computer Nerd Kev wrote:
I used to use browsershots.org to test cross-compatibility of my
websites, but it's down now and it looks like it's been that way
for at least a few months. Other services that I've found are all
free trials, is there a good permanently-free alternative like
Browsershots hiding somewhere? Or another instance of Browsershots
(since it's open-source)?
I only need screenshots of static webpages in a range of browsers.
None of this interactive testing stuff that the commercial
services seem to be pushing.
The only online service I know is browserling.com (no registration
required), but even that is only limited to 3 minutes of each testing session.
I used to use browsershots.org to test cross-compatibility of my
websites, but it's down now and it looks like it's been that way
for at least a few months. Other services that I've found are all
free trials, is there a good permanently-free alternative like
Browsershots hiding somewhere? Or another instance of Browsershots
(since it's open-source)?
I used to use browsershots.org to test cross-compatibility of my
websites, but it's down now and it looks like it's been that way
for at least a few months. Other services that I've found are all
free trials, is there a good permanently-free alternative like
Browsershots hiding somewhere? Or another instance of Browsershots
(since it's open-source)?
I only need screenshots of static webpages in a range of browsers.
None of this interactive testing stuff that the commercial
services seem to be pushing.
I use the W3C (World Wide Web Consortium) test tools. I test the HTML
of a Web page at <http://validator.w3.org/>
and the CSS at <http://jigsaw.w3.org/css-validator/>.
If a Web page passes these tests but does not display in a
browser correctly, it is the fault of the browser and not of the
Web page.
Also there is <https://www.w3.org/WAI/test-evaluate/tools/selecting/> regarding testing the accessibility for the handicapped. For the Web
site of a commercial entity in the United States, this can be important.
The Target chain of stores settled an Americans with Disaplities Act
(ADA) lawsuit for $6,000,000 because its Web site could not be processed
by an audio browser for the blind.
Computer Nerd Kev, 2025-03-03 04:17:
I used to use browsershots.org to test cross-compatibility of my
websites, but it's down now and it looks like it's been that way
for at least a few months. Other services that I've found are all
free trials, is there a good permanently-free alternative like
Browsershots hiding somewhere? Or another instance of Browsershots
(since it's open-source)?
Well - what Browsers are left to test?
Most browsers are Chromium-based anyway (Chrome, Edge, Vivaldi, Brave etc.).
Then there is Safari with about 18% market share and Firefox with less
then 3% market share:
<https://gs.statcounter.com/browser-market-share>
You may try Selenium or Cyrpess to do browser testing - both tools also
have the ability to create screen shots and support multiple browsers as well:
<https://www.selenium.dev>
<https://www.cypress.io>
Then there is Safari with about 18% market share ...
https://gs.statcounter.com/browser-market-share
I don't use CSS ...
David E. Ross <nobody@nowhere.invalid> wrote:[...]
[...]If a Web page passes these tests but does not display in a
browser correctly, it is the fault of the browser and not of the
Web page.
But for one thing the standard isn't always as explicit as you want
it to be, so I want to see when a HTML tag varies wildly in effect
and maybe avoid using it if it makes the layout confusing in some
browsers. The indentation used in <dl>, for instanace, can vary,
potentially making a page difficult to read in some browsers while
it's fine in others. You might say "well don't use that then", but
if I don't test how do I know what not to use? Not by copying what
Arno Welzel <usenet@arnowelzel.de> wrote:
Computer Nerd Kev, 2025-03-03 04:17:
I used to use browsershots.org to test cross-compatibility of my
websites, but it's down now and it looks like it's been that way
for at least a few months. Other services that I've found are all
free trials, is there a good permanently-free alternative like
Browsershots hiding somewhere? Or another instance of Browsershots
(since it's open-source)?
Well - what Browsers are left to test?
Most browsers are Chromium-based anyway (Chrome, Edge, Vivaldi, Brave etc.). >>
Then there is Safari with about 18% market share and Firefox with less
then 3% market share:
<https://gs.statcounter.com/browser-market-share>
I use Dillo during development, since it's my preferred browser,
Since usage share stats don't reflect my own use of the Web, I
don't pay them much attention. They're just the reason _I_ can't
browse some other people's websites in Dillo because they followed
that philosophy.
On Thu, 6 Mar 2025 11:21:45 +0100, Arno Welzel wrote:
Then there is Safari with about 18% market share ...
How can that be, when it doesn’t run on Windows?
Computer Nerd Kev, 2025-03-06 23:48:
David E. Ross <nobody@nowhere.invalid> wrote:[...]
[...]If a Web page passes these tests but does not display in a
browser correctly, it is the fault of the browser and not of the
Web page.
But for one thing the standard isn't always as explicit as you want
it to be, so I want to see when a HTML tag varies wildly in effect
and maybe avoid using it if it makes the layout confusing in some
browsers. The indentation used in <dl>, for instanace, can vary,
potentially making a page difficult to read in some browsers while
it's fine in others. You might say "well don't use that then", but
if I don't test how do I know what not to use? Not by copying what
HTML was *never* intended to specify an *exact* way how things will be displayed. It is *markup* and defines the *structure* of a document.
Computer Nerd Kev, 2025-03-06 23:17:
I use Dillo during development, since it's my preferred browser,
Maybe my other post did not arrive here, so in short:
Dillo is lacking many current standards an will not display website
correctly even if they are totally fine.
See their FAQ: <https://dillo.org/FAQ.html#q7>
Since usage share stats don't reflect my own use of the Web, I
don't pay them much attention. They're just the reason _I_ can't
browse some other people's websites in Dillo because they followed
that philosophy.
No, it is because Dillo does not work properly.
For my own website,
<https://arnowelzel.de> it states "Zero detected HTML errors" (which is correct - I care for correct HTML), but still the site is not rendered correctly since Dillo lacks support for current standards like "float"
in CSS.
Arno Welzel <usenet@arnowelzel.de> wrote:
Computer Nerd Kev, 2025-03-06 23:48:
David E. Ross <nobody@nowhere.invalid> wrote:[...]
[...]If a Web page passes these tests but does not display in a
browser correctly, it is the fault of the browser and not of the
Web page.
But for one thing the standard isn't always as explicit as you want
it to be, so I want to see when a HTML tag varies wildly in effect
and maybe avoid using it if it makes the layout confusing in some
browsers. The indentation used in <dl>, for instanace, can vary,
potentially making a page difficult to read in some browsers while
it's fine in others. You might say "well don't use that then", but
if I don't test how do I know what not to use? Not by copying what
HTML was *never* intended to specify an *exact* way how things will be
displayed. It is *markup* and defines the *structure* of a document.
I think browsers display most HTML fine without imposing all sorts
of specifics on them with CSS, I just like to check between them to
catch any exceptions to that.
Computer Nerd Kev, 2025-03-07 13:14:
Arno Welzel <usenet@arnowelzel.de> wrote:
HTML was *never* intended to specify an *exact* way how things will be
displayed. It is *markup* and defines the *structure* of a document.
I think browsers display most HTML fine without imposing all sorts
of specifics on them with CSS, I just like to check between them to
catch any exceptions to that.
You don't even understand the topic, relly.
The advantages of a separate sytlesheet are also moot if you don't
intend to specify an overly-specific fashionable page design which
you'll want updated whenever tastes change.
Lawrence D'Oliveiro, 2025-03-07 03:05:
On Thu, 6 Mar 2025 11:21:45 +0100, Arno Welzel wrote:
Then there is Safari with about 18% market share ...
How can that be, when it doesn’t run on Windows?
Because iOS uses Safari as the main browser and iPhones have a market
share of nearly 50% in some regions.
Arno Welzel <usenet@arnowelzel.de> wrote:
Computer Nerd Kev, 2025-03-07 13:14:
Arno Welzel <usenet@arnowelzel.de> wrote:
HTML was *never* intended to specify an *exact* way how things will be >>>> displayed. It is *markup* and defines the *structure* of a document.
I think browsers display most HTML fine without imposing all sorts
of specifics on them with CSS, I just like to check between them to
catch any exceptions to that.
You don't even understand the topic, relly.
I understand that CSS allows specifying display attributes for HTML
elements. It's just not needed if the HTML elements used are
general enough that they display sensibly by default in all
browsers. Then you don't need the extra complexity of CSS, or
complex web browsers that support it all.
The advantages of a separate sytlesheet are also moot if you don't
intend to specify an overly-specific fashionable page design which
you'll want updated whenever tastes change. If the information
doesn't change, the page shouldn't change.
On Fri, 7 Mar 2025 08:26:37 +0100, Arno Welzel wrote:
Lawrence D'Oliveiro, 2025-03-07 03:05:
On Thu, 6 Mar 2025 11:21:45 +0100, Arno Welzel wrote:
Then there is Safari with about 18% market share ...
How can that be, when it doesn’t run on Windows?
Because iOS uses Safari as the main browser and iPhones have a market
share of nearly 50% in some regions.
And the entire smartphone market is several times bigger than the desktop market. But there is no indication of how much each is contributing to
those dubious Statcounter figures.
On 8 Mar 2025 07:35:30 +1000, Computer Nerd Kev wrote:
The advantages of a separate sytlesheet are also moot if you don't
intend to specify an overly-specific fashionable page design which
you'll want updated whenever tastes change.
It?s a bit more than just about fashionable tastes. It?s also about repurposing content. For example, there is a common need to display web
pages not just on a regular-sized desktop/laptop monitor, but also on a smartphone screen. CSS provides a mechanism for automatically sensing the class of UA, and adapting the formatting accordingly.
Computer Nerd Kev, 2025-03-07 22:35:
Arno Welzel <usenet@arnowelzel.de> wrote:
Computer Nerd Kev, 2025-03-07 13:14:
Arno Welzel <usenet@arnowelzel.de> wrote:
HTML was *never* intended to specify an *exact* way how things will be >>>>> displayed. It is *markup* and defines the *structure* of a document.
I think browsers display most HTML fine without imposing all sorts
of specifics on them with CSS, I just like to check between them to
catch any exceptions to that.
You don't even understand the topic, relly.
I understand that CSS allows specifying display attributes for HTML
elements. It's just not needed if the HTML elements used are
general enough that they display sensibly by default in all
browsers. Then you don't need the extra complexity of CSS, or
complex web browsers that support it all.
CSS does not only "allow" something, in fact nearly ever browser has
build in a set of default CSS rules for all known HTML elements.
Therefore it is also a very common practice to create a basic stylesheet
for a website to define the overall look of it and *not* to rely on only
how browsers render elements by default.
The advantages of a separate sytlesheet are also moot if you don't
intend to specify an overly-specific fashionable page design which
you'll want updated whenever tastes change. If the information
doesn't change, the page shouldn't change.
You seem to lack knowledge here as well.
Browsers cache resources. Well maintained websites and servers also
provide expire headers to make sure, caching is done properly - for
example for a longer time period of days, weeks or even months for
resources which only change rarely, combined with versioned URLs to make sure, updates are possible when needed.
An external stylesheet which applies to a website can be cached *once*
and then be used many times without even loading it from the webserver
again.
CSS is nowadays just an integral part of webdesign. And "webdesign" is
not just there to have and "overly-specific fashionable page design" but
to create *design* at all. "Design" is a tool to make things *usable*
and provide an individual look as well.
If you don't want to design anything at all you also don't need services
like Browsershots - because then it is *not* important, how things look!
You just write valid HTML and it will work. It is not important, how
much indentation a browser uses for lists.
However - you *do* care about design, quote:
"The indentation used in <dl>, for instanace, can vary, potentially
making a page difficult to read in some browsers while it's fine in others."
And because of this, there is CSS to be able to make sure, that a
definition list is displayed always in the same way regardless what
browser is used.
If you create a book for example, you also think about how your page
layout should look in the end, what fonts you want to use, how to
arrange certain elements to make it easy for the readers and to express
your own "style". Technically this would not be neccessary - you can
just use a fixed width font and don't do any design at all. But still,
most books are not just plain text but use different fonts for headings
and body text, come in different sizes and aspect ratios and so on.
The web is not that different in this manner
- it is just a different
medium, but the days where "world wide web" only means pure HTML and
nothing else are long gone and browsers like Dillo are just a very niche product which has no meaning at all when it comes to web as it is today. Complaining about how bad HTML with CSS is, because Dillo is not able to handle it, is pointless - because it is Dillo which lacks full support
of well defined standards and not the standards are the problem.
Lawrence D'Oliveiro, 2025-03-08 02:09:
On Fri, 7 Mar 2025 08:26:37 +0100, Arno Welzel wrote:
Lawrence D'Oliveiro, 2025-03-07 03:05:
On Thu, 6 Mar 2025 11:21:45 +0100, Arno Welzel wrote:
Then there is Safari with about 18% market share ...
How can that be, when it doesn’t run on Windows?
Because iOS uses Safari as the main browser and iPhones have a market
share of nearly 50% in some regions.
And the entire smartphone market is several times bigger than the
desktop market. But there is no indication of how much each is
contributing to those dubious Statcounter figures.
Then use the specific statistics - for example the browser version
statistics and just enable "Safari iPhone" which is still around 14%:
<https://gs.statcounter.com/browser-version-market-share>
If you keep the formatting simple enough ...
Arno Welzel <usenet@arnowelzel.de> wrote:[...]>> Therefore it is also a very common practice to create a basic stylesheet
for a website to define the overall look of it and *not* to rely on only
how browsers render elements by default.
No, the defaults (plus user preferences) should in general do the
job. Sometimes some browsers have poor defaults, so avoid those
elements or use CSS. The former keeps things simpler and more
compatible.
provide expire headers to make sure, caching is done properly - for
example for a longer time period of days, weeks or even months for
resources which only change rarely, combined with versioned URLs to make
sure, updates are possible when needed.
An external stylesheet which applies to a website can be cached *once*
and then be used many times without even loading it from the webserver
again.
Yeah, same with a static page of HTML without CSS, or in fact _any_
file sent over HTTP. But I don't know why you're telling me this, I
think there's some mis-communication. One advantage of CSS is you
can change one stylesheet to alter the display of a whole website,
I'm saying it's not useful unless you're doing excessive amounts of
'styling' in the first place, so not a reason for me to adopt it.
Nothing to do with caching.
"The indentation used in <dl>, for instanace, can vary, potentially
making a page difficult to read in some browsers while it's fine in others." >>
And because of this, there is CSS to be able to make sure, that a
definition list is displayed always in the same way regardless what
browser is used.
Or what I did which was to use headings and paragraphs instead of
<dl> in one instance so that the difference between terms and
descriptions was always clear. Not always "in the same way", but
On Sat, 8 Mar 2025 02:32:55 +0100, Arno Welzel wrote:[...]>> Then use the specific statistics - for example the browser version
statistics and just enable "Safari iPhone" which is still around 14%:
<https://gs.statcounter.com/browser-version-market-share>
The fact remains, Statcounter no longer collects a sufficiently representative set of statistics to be the basis for concluding anything. <https://www.zdnet.com/article/statcounters-windows-market-share-data-is-not-accurate-or-reliable-and-i-can-prove-it/
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On 8 Mar 2025 07:35:30 +1000, Computer Nerd Kev wrote:
The advantages of a separate sytlesheet are also moot if you don't
intend to specify an overly-specific fashionable page design which
you'll want updated whenever tastes change.
It?s a bit more than just about fashionable tastes. It?s also about
repurposing content. For example, there is a common need to display web
pages not just on a regular-sized desktop/laptop monitor, but also on a
smartphone screen. CSS provides a mechanism for automatically sensing the
class of UA, and adapting the formatting accordingly.
If you keep the formatting simple enough you can just add:
<meta name="viewport" content="width=device-width">
in <head> and it'll work on smartphones without any special CSS
rules.
Computer Nerd Kev, 2025-03-08 04:10:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On 8 Mar 2025 07:35:30 +1000, Computer Nerd Kev wrote:
The advantages of a separate sytlesheet are also moot if you don't
intend to specify an overly-specific fashionable page design which
you'll want updated whenever tastes change.
It?s a bit more than just about fashionable tastes. It?s also about
repurposing content. For example, there is a common need to display web
pages not just on a regular-sized desktop/laptop monitor, but also on a
smartphone screen. CSS provides a mechanism for automatically sensing the >> class of UA, and adapting the formatting accordingly.
If you keep the formatting simple enough you can just add:
<meta name="viewport" content="width=device-width">
in <head> and it'll work on smartphones without any special CSS
rules.
It won't in most cases, since most content does *not* work on small
viewports if you don't take care to have viewport specific rules.
Computer Nerd Kev, 2025-03-08 05:07:
Sometimes some browsers have poor defaults, so avoid those
elements or use CSS. The former keeps things simpler and more
compatible.
No. "More compatible" means in *your* own terms, that you can not be
sure, how things get displyed. If you want to make sure, things show in
the same way, regardless what browser one uses, then use CSS.
[...]>> Browsers cache resources. Well maintained websites and servers also
provide expire headers to make sure, caching is done properly - for
example for a longer time period of days, weeks or even months for
resources which only change rarely, combined with versioned URLs to make >>> sure, updates are possible when needed.
An external stylesheet which applies to a website can be cached *once*
and then be used many times without even loading it from the webserver
again.
Yeah, same with a static page of HTML without CSS, or in fact _any_
file sent over HTTP. But I don't know why you're telling me this, I
think there's some mis-communication. One advantage of CSS is you
can change one stylesheet to alter the display of a whole website,
I'm saying it's not useful unless you're doing excessive amounts of
'styling' in the first place, so not a reason for me to adopt it.
Nothing to do with caching.
It has *nothing* to do with "excessive amounts of 'styling'"!
Every CSS should be an external file, so there is only *one* place to
define the layout of a website. It makes no sense to have CSS rules
within the HTML files if you have to repeat them on every single page
where you want to change the look of any element.
[...]>> However - you *do* care about design, quote:
"The indentation used in <dl>, for instanace, can vary, potentially
making a page difficult to read in some browsers while it's fine in others."
And because of this, there is CSS to be able to make sure, that a
definition list is displayed always in the same way regardless what
browser is used.
Or what I did which was to use headings and paragraphs instead of
<dl> in one instance so that the difference between terms and
descriptions was always clear. Not always "in the same way", but
But <dl> has a meaning. It is *not* there to have a specific "look" but
to define the *structure* of a document.
[...]> We have a standard, HTML 4.01 Transitional, which supports all the
No, we now have HTML5: <https://html.spec.whatwg.org>
Everything else is outdated and only supported by browsers for backwards compatibility.
Lawrence D'Oliveiro, 2025-03-08 07:13:
On Sat, 8 Mar 2025 02:32:55 +0100, Arno Welzel wrote:[...]>> Then use the specific statistics - for example the browser
version
statistics and just enable "Safari iPhone" which is still around 14%:
<https://gs.statcounter.com/browser-version-market-share>
The fact remains, Statcounter no longer collects a sufficiently
representative set of statistics to be the basis for concluding
anything.
<https://www.zdnet.com/article/statcounters-windows-market-share-data-is-not-accurate-or-reliable-and-i-can-prove-it/
You're welcome to present a more reliable statistic.
On Sat, 8 Mar 2025 15:47:51 +0100, Arno Welzel wrote:
Lawrence D'Oliveiro, 2025-03-08 07:13:
On Sat, 8 Mar 2025 02:32:55 +0100, Arno Welzel wrote:[...]>> Then use the specific statistics - for example the browser
version
statistics and just enable "Safari iPhone" which is still around 14%:
<https://gs.statcounter.com/browser-version-market-share>
The fact remains, Statcounter no longer collects a sufficiently
representative set of statistics to be the basis for concluding
anything.
<https://www.zdnet.com/article/statcounters-windows-market-share-data-is-not-accurate-or-reliable-and-i-can-prove-it/
You're welcome to present a more reliable statistic.
You were the one trying to make some point about market share, not me.
Arno Welzel <usenet@arnowelzel.de> wrote:
Computer Nerd Kev, 2025-03-08 05:07:
It has *nothing* to do with "excessive amounts of 'styling'"!
Every CSS should be an external file, so there is only *one* place to
define the layout of a website. It makes no sense to have CSS rules
within the HTML files if you have to repeat them on every single page
where you want to change the look of any element.
Oh I see, you're just saying that if you're going to use CSS it's
better to have it in a separate stylesheet to avoid re-downloading.
I was saying that the other advantage of separate stylesheets -
being able to revise the look of a whole site by editing one file
so eg. <h2> elements now look like <h3> did before, instead of
replacing every <h2> with <h3> in the HTML of every page - is
pointless to me. I don't want to change the look of pages, and
headings can be displayed how browsers like (the actual sizes vary browser-to-browser and that's fine, I don't mind, so long as
they're clearly shown as a heading).
to define the *structure* of a document.
Yet if browsers don't make that structure clear by default, because
Your argument about meaning contradicts itself anyway. You can use
[...]> We have a standard, HTML 4.01 Transitional, which supports all the
No, we now have HTML5: <https://html.spec.whatwg.org>
Everything else is outdated and only supported by browsers for backwards
compatibility.
Including backwards compatible with my websites, so I can
blissfully ignore HTML5 and follow the standards that fit my own compatibility requirements.
Computer Nerd Kev, 2025-03-08 23:27:
Arno Welzel <usenet@arnowelzel.de> wrote:
Computer Nerd Kev, 2025-03-08 05:07:I was saying that the other advantage of separate stylesheets -
being able to revise the look of a whole site by editing one file
so eg. <h2> elements now look like <h3> did before, instead of
replacing every <h2> with <h3> in the HTML of every page - is
pointless to me. I don't want to change the look of pages, and
headings can be displayed how browsers like (the actual sizes vary
browser-to-browser and that's fine, I don't mind, so long as
they're clearly shown as a heading).
Which is always the case - headings will always be shown as headings.
But you(!) complained about that <DL> will not always be recognizable as definition list and *instead* using CSS to make sure, the layout looks
as you want it to be, you replace <DL> with headings and paragraphs
which is exactly the opposite what HTML is meant for. If you want to
change the *look* of things, then use CSS and not different HTML elements!
[...]>> But <dl> has a meaning. It is *not* there to have a specific
"look" but
to define the *structure* of a document.
Yet if browsers don't make that structure clear by default, because
Then use CSS for it to make that clear! But the *meaning* of <DL> is
still the same, no matter what the browser *displays* for it.
[...]
Your argument about meaning contradicts itself anyway. You can use
No, it is not "my argument". That is the official definition of HTML,
the "Hypertext Markup Language".
See: <https://html.spec.whatwg.org/#semantics-2>
Quote:
"3.2.1 Semantics
Elements, attributes, and attribute values in HTML are defined (by this specification) to have certain meanings (semantics). For example, the ol element represents an ordered list, and the lang attribute represents
the language of the content.
These definitions allow HTML processors, such as web browsers or search engines, to present and use documents and applications in a wide variety
of contexts that the author might not have considered.
[...]> We have a standard, HTML 4.01 Transitional, which supports all the >>>
No, we now have HTML5: <https://html.spec.whatwg.org>
Everything else is outdated and only supported by browsers for backwards >>> compatibility.
Including backwards compatible with my websites, so I can
blissfully ignore HTML5 and follow the standards that fit my own
compatibility requirements.
No, you can't. HTML5 is *not* fully backwards compatible!
It's just browsers which try to keep compatible. But the standard
is now HTML5 only. All older standards are *obselete* and should
*not* be used any longer!
"W3C Recommendation 24 December 1999
superseded 27 March 2018"
You understand the meaning of "superseded 27 March 2018"? Start living
in the present! The days of Internet Explorer and Netscape Navigator are
long gone.
Arno Welzel <usenet@arnowelzel.de> wrote:[...]
But you(!) complained about that <DL> will not always be recognizable as
definition list and *instead* using CSS to make sure, the layout looks
as you want it to be, you replace <DL> with headings and paragraphs
which is exactly the opposite what HTML is meant for. If you want to
change the *look* of things, then use CSS and not different HTML elements!
Then what's <dl> mean to someone reading the doc if you've changed
the look? If they have a browser which renders an element like <dl>
clearly, even if others don't, the CSS has just overriden that
rendering and obscured the meaning. The user doesn't know if it's
a definition list, or just a bunch of headings and paragraphs,
because you've broken the default rendering with CSS. Using <dl> is
pointless then except for people reading the HTML/CSS code itself!
Then use CSS for it to make that clear! But the *meaning* of <DL> is
still the same, no matter what the browser *displays* for it.
It will never be clear what a <dl> (or any element) looks like if
every website has CSS which makes it look different. Stick to
elements that all browsers display clearly without CSS, and users
_can_ actually tell the *meaning* of those elements if you _don't_
use CSS.
[...]
Your argument about meaning contradicts itself anyway. You can use
No, it is not "my argument". That is the official definition of HTML,
the "Hypertext Markup Language".
Yes because HTML is now designed for people who love CSS because it
lets them easily change their website's look every few years to
stay fashionable, and therefore causes all the problems I've
mentioned about usability, as well as make browsers more
complicated to support the CSS standards.
No, you can't. HTML5 is *not* fully backwards compatible!
I don't claim my pages are HTML5, they have a <!DOCTYPE> header
which states they're HTML 4.01 Transitional.
It's just browsers which try to keep compatible. But the standard
is now HTML5 only. All older standards are *obselete* and should
*not* be used any longer!
Stuff 'em! The standard exists, browsers support it (<!DOCTYPE>
I'd rather switch to Gemini (an unofficial standard) or Gopher
(an older official standard), than HTML5/CSS. But why? Because
someone says I have to use CSS now with HTML? No authority can
dictate what standard I can use online, which I'm doubly thankful
for because the Web standards publishers are led by the nose by
commercial interests (mainly Google) now anyway.
"W3C Recommendation 24 December 1999
superseded 27 March 2018"
You understand the meaning of "superseded 27 March 2018"? Start living
in the present! The days of Internet Explorer and Netscape Navigator are
long gone.
Yeah now it's all about Google Chrome, which I don't use, and
Google can get the W3C to recommend all sorts of sillyness. They're
Lawrence D'Oliveiro, 2025-03-09 09:05:
On Sat, 8 Mar 2025 15:47:51 +0100, Arno Welzel wrote:
Lawrence D'Oliveiro, 2025-03-08 07:13:
On Sat, 8 Mar 2025 02:32:55 +0100, Arno Welzel wrote:[...]>> Then use the specific statistics - for example the browser
version
statistics and just enable "Safari iPhone" which is still around
14%:
<https://gs.statcounter.com/browser-version-market-share>
The fact remains, Statcounter no longer collects a sufficiently
representative set of statistics to be the basis for concluding
anything.
<https://www.zdnet.com/article/statcounters-windows-market-share-data-is-not-accurate-or-reliable-and-i-can-prove-it/
You're welcome to present a more reliable statistic.
You were the one trying to make some point about market share, not me.
But you are telling the market share is not reliable, not me.
On Sun, 9 Mar 2025 12:08:28 +0100, Arno Welzel wrote:
Lawrence D'Oliveiro, 2025-03-09 09:05:
On Sat, 8 Mar 2025 15:47:51 +0100, Arno Welzel wrote:
Lawrence D'Oliveiro, 2025-03-08 07:13:
On Sat, 8 Mar 2025 02:32:55 +0100, Arno Welzel wrote:[...]>> Then use the specific statistics - for example the browser
version
statistics and just enable "Safari iPhone" which is still around
14%:
<https://gs.statcounter.com/browser-version-market-share>
The fact remains, Statcounter no longer collects a sufficiently
representative set of statistics to be the basis for concluding
anything.
<https://www.zdnet.com/article/statcounters-windows-market-share-data-is-not-accurate-or-reliable-and-i-can-prove-it/
You're welcome to present a more reliable statistic.
You were the one trying to make some point about market share, not me.
But you are telling the market share is not reliable, not me.
Correct. In other words, you didn’t have a point.
Computer Nerd Kev, 2025-03-09 23:38:
Arno Welzel <usenet@arnowelzel.de> wrote:[...]
But you(!) complained about that <DL> will not always be recognizable as >>> definition list and *instead* using CSS to make sure, the layout looksThen what's <dl> mean to someone reading the doc if you've changed
as you want it to be, you replace <DL> with headings and paragraphs
which is exactly the opposite what HTML is meant for. If you want to
change the *look* of things, then use CSS and not different HTML elements! >>
the look? If they have a browser which renders an element like <dl>
It still means the same. The *semantics* will not change. Stop thinking always about how things *look*.
Elements have a semantic meaning. And how this used also depends
on the context.
Some websites build their menus based on <ul> and <li> for the menu
items. Even if the menus is not really a visual list, the "list"
semantic may still work better than having multiple paragraphs or <div> elements.
Your argument about meaning contradicts itself anyway. You can use
No, it is not "my argument". That is the official definition of HTML,
the "Hypertext Markup Language".
Yes because HTML is now designed for people who love CSS because it
lets them easily change their website's look every few years to
stay fashionable, and therefore causes all the problems I've
mentioned about usability, as well as make browsers more
complicated to support the CSS standards.
Wrong. It's about *semantic*. And that's why CSS was invented even back
then, when HTML 4 was still a thing - to be able to design content
without abusing *semantic* to get a different look.
I'd rather switch to Gemini (an unofficial standard) or Gopher
(an older official standard), than HTML5/CSS. But why? Because
someone says I have to use CSS now with HTML? No authority can
dictate what standard I can use online, which I'm doubly thankful
for because the Web standards publishers are led by the nose by
commercial interests (mainly Google) now anyway.
I never said, that you *must* use CSS. But if *you* complain about <dl>
not looking as you would like to have it, *then* you have to use CSS and should *not* use a different element instead, just to make things look different.
"W3C Recommendation 24 December 1999
superseded 27 March 2018"
You understand the meaning of "superseded 27 March 2018"? Start living
in the present! The days of Internet Explorer and Netscape Navigator are >>> long gone.
Yeah now it's all about Google Chrome, which I don't use, and
No, it's also about Firefox, Safari and nearly every other modern
browser support this.
Google can get the W3C to recommend all sorts of sillyness. They're
No, it is *not* Google telling others what to do!
See <https://whatwg.org/sg-agreement>:
"The initial Steering Group Members are the four Qualifying Entities identified below: Mozilla Corporation, Microsoft Corporation, Google
LLC, and Apple Inc."
And also all these people:
<https://html.spec.whatwg.org/multipage/acknowledgements.html#acknowledgments>
Of course you can ignore the development of the past 10 years and stick
with a nearly 25 year old standard (HTML 4.01 was specified by the end
of 1999!)
but calling HTML5 something "forced by Google" is just bullshit.
Well - other sources have the similar values:
<https://radar.cloudflare.com/reports/browser-market-share-2024-q4#id-5-global-market-share>
Arno Welzel <usenet@arnowelzel.de> wrote:
Computer Nerd Kev, 2025-03-09 23:38:
Arno Welzel <usenet@arnowelzel.de> wrote:[...]
But you(!) complained about that <DL> will not always be recognizable as >>>> definition list and *instead* using CSS to make sure, the layout looks >>>> as you want it to be, you replace <DL> with headings and paragraphsThen what's <dl> mean to someone reading the doc if you've changed
which is exactly the opposite what HTML is meant for. If you want to
change the *look* of things, then use CSS and not different HTML elements! >>>
the look? If they have a browser which renders an element like <dl>
It still means the same. The *semantics* will not change. Stop thinking
always about how things *look*.
Yes you're so wrapped up in the semantics of the standards that you
miss that the idea isn't for people to read the raw HTML and see
"this is a <dl>" and "that's a <ul>" and "I can go back to the
rendered page and click on this because it's an <a>". The meaning
for the user has to be conveyed by how things look, and changing it
with CSS, or using elements that some browsers render unclearly,
just obscures that meaning. That's the practical reality.
but calling HTML5 something "forced by Google" is just bullshit.
Well they can't force HTML5 to be adopted by people like me who
don't like it, and don't even use their browser. Glad you sort-of
agree.
On Mon, 10 Mar 2025 19:32:01 +0100, Arno Welzel wrote:
Well - other sources have the similar values:
<https://radar.cloudflare.com/reports/browser-market-share-2024-q4#id-5-global-market-share>
Or maybe they suffer the same biases. Without insight into their
methodology, you can’t be sure.
Presumably Cloudflare is only measuring browser stats for hits on the
sites it serves.
Since Cloudflare serves 25 million sites, these values look quite
plausible to me.
Computer Nerd Kev, 2025-03-11 01:37:
Arno Welzel <usenet@arnowelzel.de> wrote:
Computer Nerd Kev, 2025-03-09 23:38:
Arno Welzel <usenet@arnowelzel.de> wrote:[...]
But you(!) complained about that <DL> will not always be recognizable as >>>>> definition list and *instead* using CSS to make sure, the layout looks >>>>> as you want it to be, you replace <DL> with headings and paragraphs
which is exactly the opposite what HTML is meant for. If you want to >>>>> change the *look* of things, then use CSS and not different HTML elements!
Then what's <dl> mean to someone reading the doc if you've changed
the look? If they have a browser which renders an element like <dl>
It still means the same. The *semantics* will not change. Stop thinking
always about how things *look*.
Yes you're so wrapped up in the semantics of the standards that you
miss that the idea isn't for people to read the raw HTML and see
"this is a <dl>" and "that's a <ul>" and "I can go back to the
rendered page and click on this because it's an <a>". The meaning
for the user has to be conveyed by how things look, and changing it
with CSS, or using elements that some browsers render unclearly,
just obscures that meaning. That's the practical reality.
No - but *software* can understand it a well. And this also means
software which helps people understand the meaning of it. For example
search engines can interpret content better and assistive technologies
can tell people, if there is a heading, paragraph or a definition list
and help them to navigate the content.
On 2025-03-11, Arno Welzel wrote:
Computer Nerd Kev, 2025-03-11 01:37:
Arno Welzel <usenet@arnowelzel.de> wrote:
It still means the same. The *semantics* will not change. Stop
thinking always about how things *look*.
Yes you're so wrapped up in the semantics of the standards that you
miss that the idea isn't for people to read the raw HTML and see
"this is a <dl>" and "that's a <ul>" and "I can go back to the
rendered page and click on this because it's an <a>". The meaning
for the user has to be conveyed by how things look, and changing
it with CSS, or using elements that some browsers render unclearly,
just obscures that meaning. That's the practical reality.
No - but *software* can understand it a well. And this also means
software which helps people understand the meaning of it. For example search engines can interpret content better and assistive technologies
can tell people, if there is a heading, paragraph or a definition list
and help them to navigate the content.
That is also a practical reality!
Well they can't force HTML5 to be adopted by people like me who
don't like it, and don't even use their browser. Glad you sort-of
agree.
Fortunately you are not responsible for the publication of any
meaningful website.
That said, from what I'm told, Chromium, regardless of how large its
"market share" might be, isn't compatible with braille displays in
the first place, and so isn't quite usable for blind users anyway,
making the point somewhat moot. The only free software browser that
is aimed at such I know of is Edbrowse, and last I've checked (though
it was a while ago), its CSS support was hardly anything to write
home about.
On 2025-03-11, Arno Welzel wrote:
Computer Nerd Kev, 2025-03-11 01:37:
Arno Welzel <usenet@arnowelzel.de> wrote:
It still means the same. The *semantics* will not change. Stop
thinking always about how things *look*.
Yes you're so wrapped up in the semantics of the standards that you
miss that the idea isn't for people to read the raw HTML and see
"this is a <dl>" and "that's a <ul>" and "I can go back to the
rendered page and click on this because it's an <a>". The meaning
for the user has to be conveyed by how things look, and changing
it with CSS, or using elements that some browsers render unclearly,
just obscures that meaning. That's the practical reality.
No - but *software* can understand it a well. And this also means
software which helps people understand the meaning of it. For example search engines can interpret content better and assistive technologies
can tell people, if there is a heading, paragraph or a definition list
and help them to navigate the content.
That is also a practical reality!
I can agree, if only in part. The idea that the meaning "has to
be conveyed by how things look" is easily countered by observing
that some of the web users /cannot/ look. I don't suppose one
can expect a bigger font for one's <h1 />s on a braille display
or speech synthesizer, right?
And if you rely on the browser's "default" rendering for your
HTML, in those browsers that /do/ support CSS, such rendering
is in fact implemented by the means of in-browser default CSS.
So it can be argued that you still rely on CSS for presentation.
Yet again: because the presentation is decided at the /reader's/
end, and if the reader is Chromium, then it's decided by CSS.
On Tue, 11 Mar 2025 08:28:54 +0100, Arno Welzel wrote:
Since Cloudflare serves 25 million sites, these values look quite
plausible to me.
But a big outfit like Cloudflare is biased towards serving bigger sites,
not smaller ones.
Ivan Shmakov <ivan@siamics.netremove.invalid> wrote:[...]
[...]And if you rely on the browser's "default" rendering for your
HTML, in those browsers that /do/ support CSS, such rendering
is in fact implemented by the means of in-browser default CSS.
So it can be argued that you still rely on CSS for presentation.
Yet again: because the presentation is decided at the /reader's/
end, and if the reader is Chromium, then it's decided by CSS.
In Dillo you can even specify the default rendering with your own
CSS stylesheet that's applied to pages without their own CSS (or all
Lawrence D'Oliveiro, 2025-03-11 21:28:
But a big outfit like Cloudflare is biased towards serving bigger
sites, not smaller ones.
It depends, on how you define "smaller".
On Thu, 13 Mar 2025 20:54:52 +0100, Arno Welzel wrote:
Lawrence D'Oliveiro, 2025-03-11 21:28:
But a big outfit like Cloudflare is biased towards serving bigger
sites, not smaller ones.
It depends, on how you define "smaller".
And then there are the really big outfits that do their own hosting.
All in all, you can’t escape the fact that Cloudflare is going to suffer from its own biases.
On 2025-03-12, Computer Nerd Kev wrote:
Ivan Shmakov <ivan@siamics.netremove.invalid> wrote:
I can agree, if only in part. The idea that the meaning "has to
be conveyed by how things look" is easily countered by observing
that some of the web users /cannot/ look. I don't suppose one
can expect a bigger font for one's <h1 />s on a braille display
or speech synthesizer, right?
I think I read somewhere a suggestion that a speech synthesizer
might use different volumes of voice for different levels of
emphasis like differnt <h?> levels. Whether that happens, or
whether it was just some standard-reader's dream, I don't know.
But with something like <dl> the standard is so vague about the circumstances for using it that attempts to optimise for it in
accessibility software might cause problems on pages whose authors
have interpreted it more broadly. In HTML4 the examples were for
using it as a glossary, but it also noted that it could be used for dialogues "with each DT naming a speaker, and each DD containing his
or her words". I see HTML5 explains a much more general range of
usage cases, where often the usefulness of the distinction of a
definition list over other elements like headings is blurry (IMHO).
FIXME: write them.</p> and <h2 >Dedication</h2><p >To JohnSmith.</p>
So rather than trying to force your way with CSS, better to stick
with the elements that all browsers already display your way by
default, and you're using HTML to communicate rather than as an
exercise in maximal permitted usage of different elements from the
standard.
In Dillo you can even specify the default rendering with your own
CSS stylesheet that's applied to pages without their own CSS (or all
pages in my case, because I disable the page author's CSS). _This_
is one use of CSS that I like - letting the user set rendering of
elements the way they like at their end. My changes to the defaults
are minor, but people who like things to look fashionable have come
up with complex stylesheets which can thus be applied to the entire
Web.
Style sheets may have three different origins: author, user, and
user agent.
To find the value for an element/property combination, user
agents must apply the following sorting order:
2. Sort according to importance (normal or important) and origin
(author, user, or user agent). In ascending order of precedence:
1. user agent declarations
2. user normal declarations
3. author normal declarations
4. author important declarations
5. user important declarations
But with something like <dl> the standard is so vague about the circumstances for using it that attempts to optimise for it in accessibility software might cause problems on pages whose authorsOn 2025-03-12, Computer Nerd Kev wrote:
have interpreted it more broadly. In HTML4 the examples were for
using it as a glossary, but it also noted that it could be used for dialogues "with each DT naming a speaker, and each DD containing his
or her words". I see HTML5 explains a much more general range of
usage cases, where often the usefulness of the distinction of a
definition list over other elements like headings is blurry (IMHO).
To me, <dl /> is just an associative list, perhaps a tad
more general than the one we have in dialects of Lisp. I'd
use <dl ><dt >Foo</dt><dd >Bar</dd></dl> in a instruction
for a human more or less in the same circumstances I'd use
'((Foo . Bar)) in a program for a Lisp interpreter.
I'd use headings like I use defun / define / defvar, then.
Whether to use a function or a data structure in any specific
case is an open question. Typographically, I'd be opposed,
as a rule, to having a heading over a few words or sentences.
Possible exceptions being <h2 >Even more details</h2><p
>FIXME: write them.</p> and <h2 >Dedication</h2><p >To John
Smith.</p>
From the Living Standard's PoV, I'd say the primary difference
is that the headings are reflected in document's outline (the
standard gives an algorithm for that; whether a particular UA
implements it is a separate question), while <dl /> items aren't.
So I suppose for the things you'd want to be in the document's
outline, use headings. Otherwise, consider <dl />.
So rather than trying to force your way with CSS, better to stick
with the elements that all browsers already display your way by
default, and you're using HTML to communicate rather than as an
exercise in maximal permitted usage of different elements from the standard.
I don't see such an approach working for me, for several reasons.
... My hunch is that Chromium doesn't directly support HTML4.
That a document with <!DOCTYPE html (whatever)> is rendered more
or less like one might expect for HTML4 is rather an evidence
of backwards compatibility of the Living Standard - and of the
use of an HTML4-look-alike CSS for defaults.
And my understanding is that such defaults exist largely for
compatibility. I won't be surprised to learn that the reason
behind at least some of the (default) CSS rules given in the
Living Standard is "because Mosaic."
Ok, I get it - you don't believe anything, you don't want to use HTML5
and CSS is bullshit for you.
On Fri, 14 Mar 2025 08:05:56 +0100, Arno Welzel wrote:
Ok, I get it - you don't believe anything, you don't want to use HTML5
and CSS is bullshit for you.
I think you’ve lost track of what you were trying to argue about.
Lawrence D'Oliveiro, 2025-03-15 03:24:
On Fri, 14 Mar 2025 08:05:56 +0100, Arno Welzel wrote:
Ok, I get it - you don't believe anything, you don't want to use HTML5
and CSS is bullshit for you.
I think you’ve lost track of what you were trying to argue about.
Well - you made it clear, that you think that statistics of CloudFlare
are biased and therefore irrelevant. You also made clear, that HTML5 is
not neccessary and CSS neither.
On Sat, 15 Mar 2025 10:14:50 +0100, Arno Welzel wrote:
Lawrence D'Oliveiro, 2025-03-15 03:24:
On Fri, 14 Mar 2025 08:05:56 +0100, Arno Welzel wrote:
Ok, I get it - you don't believe anything, you don't want to use HTML5 >>>> and CSS is bullshit for you.
I think you’ve lost track of what you were trying to argue about.
Well - you made it clear, that you think that statistics of CloudFlare
are biased and therefore irrelevant. You also made clear, that HTML5 is
not neccessary and CSS neither.
Tell me again, what is the connection between the two?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 165:15:33 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,521 |