«

On 23 mai, 14:57, "Jukka K. Korpela" <jkorp...@cs.tut.fi> wrote:
> GTalbot wrote:

> > 4- <ol start="number"> *no CSS counterpart
> > but there is counter-reset for this and list-style-type: decimal.
>
> That does not correspond to the start attribute, which affects the number in
> the numbering that browsers generate by default for <ol>. If you use
> counters, you must specifically _suppress_ such numbering,

list-style-type: none suppress such numbering.

> otherwise you
> will get two numbers for each item. This means that the rendering will be
> different, except by accident.

Ok. I created a testpage on this:

CSS replacement for <ol start="42">
http://www.gtalbot.org/BrowserBugsSe...attribute.html

2 rules and 4 declarations is all that is needed.

It works as expected in Firefox 3.6.3, Opera 10.10, Konqueror 4.4.3,
Chrome 5.0.375.55. It should work in IE8.

regards, Gérard
--
Internet Explorer 7 bugs: 185 bugs so far
http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/
Internet Explorer 8 bugs: 60 bugs so far
http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/
Contributions to CSS 2.1 test suite from web authors:
http://www.gtalbot.org/BrowserBugsSe...ss21testsuite/

In article
<78092639-9b2a-41c7-8dfa-
m>,
GTalbot <> wrote:

> CSS replacement for <ol start="42">
> http://www.gtalbot.org/BrowserBugsSe...lacement-list-
> start-attribute.html

Dangerous if CSS is off, imagine if the steps were algorithm for
bomb making and suddenly the 42nd step is step number one...

--
dorayme

Neil Gould wrote:

> There are some presentational situations (beyond intranet) that are best
> served by the use of frames, and there is no CSS equivalent that works with
> all browsers, as frames do. There are facilities within the existing frames
> model to address almost every concern that I've read from those who oppose
> their usage, and I haven't seen one legitimate concern for dropping them
> (no, I don't need to re-read the "frames are evil" drivel) so AFAICT, there
> isn't a good reason NOT to use frames if they're the best solution to a
> presentational requirement.
>

Ugh! Again...

Simple reason: because a much better implementation can be done via
server-side scripting. Frames was a Netscape invention to accommodate
document modular assembly at a time when server-side technologies were
very limited. That is not the case now, and even Netscape abandoned
using frames shortly after their introduction. Frames are a little like
White-Out, indispensable in the age of typewriters but obsolete in the
age of Word Processors.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

GTalbot wrote:

> CSS replacement for <ol start="42">
> http://www.gtalbot.org/BrowserBugsSe...attribute.html
>
> 2 rules and 4 declarations is all that is needed.
>
> It works as expected in Firefox 3.6.3, Opera 10.10, Konqueror 4.4.3,
> Chrome 5.0.375.55. It should work in IE8.

It "works" in IE 8 as well, in the same sense as on other browsers you
mentioned: when style sheet support is enabled, it creates a numbered list
with numbering starting at 42.

But it does _not_ work as a replacement for <ol start="42"> in the sense of
creating the same appearance. The left indentation is different, and so is
the spacing between the number and the item text. You can add rules to
affect that, but the effect depends on the browser, as the spacing of the
numbers generated by browsers by default for <ol> may vary.

Now you might say that this is irrelevant and that CSS-generated spacing can
be more consistent and that pages should not rely on details of spacing. And
I might agree, mostly. But you still cannot replace the start="42" attribute
by CSS code that creates the _same_ effect. Similar, maybe essentially
similar, and maybe much better - but still not the same.

And there are lots of web pages that rely in details of formatting, so the
cleanup could actually do some harm.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

On 26 mai, 23:52, dorayme <dora...@optusnet.com.au> wrote:

> Authors decide all sorts of things for users. Users often have
> not a clue what they really want to do. Right click and open in
> another tab indeed! Do you really dream that the average person
> on the Clapham bus would know such a thing? There is a super
> idealised caricature of the user that is behind the idea that
> target should *never* be used.

A very wide majority of graphical web browsers (IE7+, Firefox 1+,
Opera 7+, Safari 3+, Konqueror 3+, Chrome 3+) in use today are tab-
capable web browsers and they all have a setting which allow users to
divert a new window (or linked reference with a target attribute) into
a new tab or into the same window. So, for a lot of reasons, the
target attribute, as originally designed, fails (or can not be ensured
that it will succeed as originally designed/planned) for a majority of
people. The least successful one (with regards to opening a new
window) must be <a href="..." target="_blank">.

"
The HTML 4.01 target attribute is primarly used to target a specified
frame but it can also target a new window or an already opened
secondary window. Clicking a link which has a target attribute will no
longer open another window (or an already opened window) if the user
has checked (...)
"
http://www.gtalbot.org/FirefoxSectio...nLinkNewWindow

regards, Gérard

GTalbot wrote:

> Instead of <wbr>, I believe there is a character entity for this...
> but it's not well supported IIRC.
>
> "­

No, it is a completely different thing. See
http://www.cs.tut.fi/~jkorpela/html/nobr.html#suggest
for a lengthy explanation.

> The point was to achieve clearer separation of style and presentation
> from content and structure.

That's a theoretical benefit - no tangible effect on the functionality or
appearance on the page, _except_ that you may break a page in converting it
(after all, we make mistakes, and computers are great in assisting us there)
and that the page won't look as it used to when CSS is off. Very marginally,
you might achieve some reduction in page size and thereby in load time, if
you manage to replace lots of <font> etc. markup by some simple CSS.

> More consistent look, more consistent
> coding manners, therefore easier to maintain, to do site-wide changes
> if needed.

Maybe - but is there a proof thereof? And maintainability and modifiability
depends on much more than Strict vs. Transitional. To create a really
maintainable and easily modifiable _site_ you would need to redesign it, not
just modify the markup. You should probably then start from selecting or
creating tools and procedures for generating the pages etc., and then you
would basically reconstruct the markup, not just convert it.

> Tuning of options to use is delicate in HTML Tidy when you're beginning
> with
> HTML Tidy.

Thanks for the heads-up. I'll keep avoiding HTML Tidy if I can.

>> 1) <ol start="42"> and <ol value="10">
>
> I would suggest to use counter-reset.

As discussed in another sub-thread, it does not do exactly the same, and it
does not work widely enough to justify the approach in WWW authoring.

>> 2) target attribute
>
> Frames are pretty much obsolete, definitely not recommendable.

The issue was converting from Transitional to Strict by replacing non-Strict
constructs by CSS, not the desirability or usefulness of such constructs.
Millions of pages use the target attribute. Hint: It cannot be replaced by
CSS, but it can be replaced by JavaScript, though here, too, you cannot
achieve _exactly_ the same effect (except by cheating: by using JavaScript
that modifies the document by adding a target attribute!).

>> 3) <small> (no defined counterpart in CSS - operates with a special
>> scale of sizes)
>
> I would suggest CSS declaration
> {font-size: smaller;}
> as a CSS replacement for <small>

One might also say font-size: 10pt, and it _might_ (just as your suggestion
_might_) have the same effect on some browsers under some conditions. Or,
more sensibly, one might say font-size: 85%, and it might, by accident, have
the same effect. The point is that <small> is of its own kind.

>>> 2-
>>> <table bordercolor="color"> . First bordercolor is invalid.
>>
>> Whether it is valid depends on the document type definition.
>
> bordercolor is not in any document type definition that I know of.

Well, that can be arranged. See
http://www.cs.tut.fi/~jkorpela/html/...d.html#tagsoup

> I am not sure. I would need to test this. I believe
> bordercolor="color" will be honored in quirks mode in a number of
> browsers with a default solid (or is it outset?) border and a default
> 2px width. When converting to HTML 4.01 strict, <table style="border-
> color: color"> may not suffice.

You're right, bordercolor also sets the border style to solid (as opposite
to outset, which is what most browsers use by default), but it's even more
complex. The effect does not depend on quirks vs. standards mode, but it
depends on browser. On Firefox, bordercolor sets only the color of the
border around the table; on IE, cell borders are affected too.

This is further evidence for my statement that it is not possible to convert
from Transitional to Strict, in a manner that preserves the original
formatting on all browsers, or even in a few major browsers. Moving from
Transitional to Strict thus involves a design change, not just mechanical
replacement.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

Neil Gould wrote:

> I agree that server-side scripting provides a lot of capability, but that
> approach adds a lot of complexity to a relatively simple presentational task
> and isn't as universally functional as frames. Although your opinion is not
> uncommon among web programmers, you still haven't provided a good reason why
> frames should be abandoned.
>

For one, savvy folks disable them to prevent falling victim to iframe
injection....

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

On 27 mai, 11:53, "Jukka K. Korpela" <jkorp...@cs.tut.fi> wrote:
> GTalbot wrote:
> > CSS replacement for <ol start="42">
> >http://www.gtalbot.org/BrowserBugsSe...e/css-replacem...
>
> > 2 rules and 4 declarations is all that is needed.
>
> > It works as expected in Firefox 3.6.3, Opera 10.10, Konqueror 4.4.3,
> > Chrome 5.0.375.55. It should work in IE8.
>
> It "works" in IE 8 as well, in the same sense as on other browsers you
> mentioned: when style sheet support is enabled, it creates a numbered list
> with numbering starting at 42.
>
> But it does _not_ work as a replacement for <ol start="42"> in the sense of
> creating the same appearance. The left indentation is different, and so is
> the spacing between the number and the item text. You can add rules to
> affect that, but the effect depends on the browser, as the spacing of the
> numbers generated by browsers by default for <ol> may vary.
>
> Now you might say that this is irrelevant and that CSS-generated spacing can
> be more consistent and that pages should not rely on details of spacing. And
> I might agree, mostly. But you still cannot replace the start="42" attribute
> by CSS code that creates the _same_ effect. Similar, maybe essentially
> similar, and maybe much better - but still not the same.

It still does not perfectly look the same; it still does not perfectly
appear the same. You may have to add a few more properties to adjust
indentation here, spacing there, etc.

> And there are lots of web pages that rely in details of formatting, so the
> cleanup could actually do some harm.

You have to test and verify before copying such code. And adjust
accordingly.

By the way,

"
The value attribute for the li element is no longer deprecated as it
is not presentational. The same goes for the start attribute of the ol
element.
"
HTML5 differences from HTML4
http://dev.w3.org/html5/html4-differ...new-attributes

Gérard

On 27 May 2010, "Jonathan N. Little" <> wrote:

> Neil Gould wrote:
>
>> I agree that server-side scripting provides a lot of capability, but
>> that approach adds a lot of complexity to a relatively simple
>> presentational task and isn't as universally functional as frames.
>> Although your opinion is not uncommon among web programmers, you
>> still haven't provided a good reason why frames should be abandoned.
>>
>
> For one, savvy folks disable them to prevent falling victim to iframe
> injection....

Ah, but which of those 5 is really good-looking?

--
Neredbojias

http://www.neredbojias.org/
http://www.neredbojias.net/

On 27 May 2010, "Jukka K. Korpela" <> wrote:

> The issue was converting from Transitional to Strict by replacing
> non-Strict constructs by CSS, not the desirability or usefulness of
> such constructs. Millions of pages use the target attribute. Hint: It
> cannot be replaced by CSS, but it can be replaced by JavaScript,
> though here, too, you cannot achieve _exactly_ the same effect
> (except by cheating: by using JavaScript that modifies the document
> by adding a target attribute!).

That isn't "cheating"; that's using the old noodle as God intended.

As for the target attribute, I earnestly believe that the w3c was
completely ill-advised in devalidating it as they did. A better
approach would have been to try to make it more useful for what it was
originally intended as in the first place.

--
Neredbojias

http://www.neredbojias.org/
http://www.neredbojias.net/