Yes, {val} is a tool for making attractive and convenient scientific notation. The look of {{tl|val}} was discussed at length on both WT:MOSNUM and WT:MOS and achieved broad support for how it works and renders numbers. It delimits numbers with narrow spaces that aren’t really “spaces”; they use CSS <span> tags to move characters. Thus, the significands can be copied and pasted into Excel where they will be treated as real numbers without the need to first hand-delete spaces.

The problem with it {val} is outlined here at…

http://en.wikipedia.org/w/index.php?title=User_talk:Jimbo_Wales&oldid=26... - Developer_support_for_parser_function

In a nutshell, about 5 to 10% of the time, {val} gives rounding errors. For instance, the expression {{val|0.55007|e=6}} will return a significand of 0.550069.

This is the product of the buggy math-based parser functions it must use. To date, notwithstanding that Jimbo is solidly behind this, and that Erik supports the production of the required parser function, no volunteer developer has stepped up to the plate with a parser function that can character-counting parser function.

Greg

On Jan 31, 2009, at 2:17 PM, Platonides wrote:

Greg L wrote:

All,

Can anyone figure out how to fix {{tl|val}} so an expression like

{{val|0.55007|e=6}}

…works properly?

Greg L

You can't figure out what it should do just from the description. I imagine you mean http://en.wikipedia.org/wiki/Template:Val "Set of templates that can be used to easily present values in scientific notation, including uncertainty" Another ugly template...

_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Sat, Jan 31, 2009 at 7:12 PM, Platonides Platonides@gmail.com wrote:

{{val}} is just a presentational template. It's trivial to create an equivalent, fixed, parserfunction.

We do not want to create a new parser function for every presentational template people come up with.

Aryeh, this reaction of “We do not want to create a new parser function for every presentational template people come up with” is understandable. However, I understand that a character-counting parser function in another form has been in the works for a long time but hasn’t proven to be reliable enough to be released into the wild.

If someone could finally develop a bullet-proof character-counting parser function, I’m quite certain that a number of valuable uses could be found for it. That is why I encourage the writing of a parser function over the effort of writing a developer’s version of a template that doesn’t work very well. The only reason {val} doesn’t work well is because it must rely upon math-based parser functions that produce rounding errors. Having said that…

The MOS and MOSNUM community has waited seven months for a version of {val} that works well for all numbers—even ones that are really big. Any developer who is willing to tackle this issue, regardless of whether it is a parser function or a revised version of {val}, would be most welcome. However, both Jimbo Wales (in particular) as well as Erik seemed to think the best way to leverage developer effort would be to produce the character-counting parser function as this would enable the production of template tools we haven’t even conceived of yet.

On Jan 31, 2009, at 5:30 PM, Platonides wrote:

Aryeh Gregor wrote:

On Sat, Jan 31, 2009 at 7:12 PM, Platonides wrote:

...

{{val}} is just a presentational template. It's trivial to create an equivalent, fixed, parserfunction.

We do not want to create a new parser function for every presentational template people come up with.

I know, that's the problem of such approach. Although it could be worth to parserify a set of stable core templates. Not only would they be faster, they would be more readable.

_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Sat, Jan 31, 2009 at 2:27 PM, Greg L greg_l_at_wikipedia@comcast.net wrote:

This is the product of the buggy math-based parser functions it must use. To date, notwithstanding that Jimbo is solidly behind this, and that Erik supports the production of the required parser function, no volunteer developer has stepped up to the plate with a parser function that can character-counting parser function.

Jimmy has absolutely no authority or expertise on technical matters such as this. His opinion on the best way to implement such presentational templates is, with respect, not necessarily informed and not binding in any way, as he does not deal with site operations or software development at this time.

While Erik may have authority over technical matters (he is Brion's boss), I would imagine that, like in any organisation, he delegates final decisions on matters such as this to Brion, who is, after all, CTO.

The approach we want to take isn't exactly clear at this time -- this discussion is being had in multiple places, and it basically boils down to a wide expansion of parser functionality (i.e. inline LUA), or the greater use of in-built parser functions for the *end* *result*, rather than for the intermediate steps required. The current approach of providing "building block" functions has been known to be reasonably untenable for some time, for performance and usability reasons (see a few threads up, Domas' rant about Cite).

On Sat, Jan 31, 2009 at 8:33 PM, Robert Rohde rarohde@gmail.com wrote:

This discussion is getting side tracked.

The real complaint here is that

{{#expr:(0.00007 * 1000 * 1000) mod 1000}} is giving 69 when it should give 70.

This is NOT a formatting issue, but rather it is bug in the #expr parser function, presumably caused by some kind of round-off error.

$ php -r 'echo (0.00007 * 1000 * 1000) % 1000 . "\n";' 69 $ php -r 'echo (int)(0.00007 * 10000000) . "\n";' 699

The issue is bog-standard floating-point error. If PHP has a decent library for exact-precision arithmetic, we could probably use that. Otherwise, template programmers will have to learn how floating-point numbers work just like all other programmers in the universe.

On Sat, Jan 31, 2009 at 11:02 PM, Robert Rohde rarohde@gmail.com wrote:

In r46671 I have added an explicit test for floating point numbers that are within 1 part in 10^10 of integers before performing round-off sensitive conversions and comparisons.

This should eliminate these errors in many cases.

But it causes other errors:

{{#expr:1e-11 = 2e-11}}

This is now (wrongly) true, while before your commit it was false. In the old way, at least users could work around the problem in the same way that programmers do: by explicit testing like

{{#expr:0.00007 * 10000000 - 700 < 1e-10}}

Now I don't think there's any way to get correct results in cases where small numbers are entered manually. Plus, it doesn't help stuff like

{{#expr:0.00000007 * 10000000 = 0.7}}

which still gives wrong results.

On Mon, Feb 2, 2009 at 1:55 PM, greg_l_at_wikipedia greg_l_at_wikipedia@comcast.net wrote:

I have a sandbox with hundreds of test numbers to exercise the {delimitnum} template. This template uses the same math-based functions as {val}. For anyone who has produced improved math functions, you can examine values on this sandbox that currently produce rounding errors and test your new math functions. The sandbox is at the following:

http://en.wikipedia.org/wiki/User:Greg_L/Delimitnum_sandbox

At the very bottom of the page (which loads slowly), is a concise list of values that all have errors.

The page is so slow that even attempting to view it times out for me.

Indeed. When Wikiipedia’s servers are cooking along, the first-time load on the sandbox is entirely tolerable. Once you’ve got it cached after that very first time, then it’s much better yet. Once you get there, you will find many, many number-sequence strategies. Some of you mathematically brighter types might even see a pattern to all those errors.

On Feb 2, 2009, at 11:31 AM, Robert Rohde wrote:

On Mon, Feb 2, 2009 at 11:17 AM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:

On Mon, Feb 2, 2009 at 1:55 PM, greg_l_at_wikipedia greg_l_at_wikipedia@comcast.net wrote:

...

I have a sandbox with hundreds of test numbers to exercise the {delimitnum} template. This template uses the same math-based functions as {val}. For anyone who has produced improved math functions, you can examine values on this sandbox that currently produce rounding errors and test your new math functions. The sandbox is at the following:

http://en.wikipedia.org/wiki/User:Greg_L/Delimitnum_sandbox

At the very bottom of the page (which loads slowly), is a concise list of values that all have errors.

The page is so slow that even attempting to view it times out for me.

It is large and slow (loaded for me after about 20 seconds), but we've also had some recent sporadic reports of routine things like watchlists being sluggish or failing to load. So, in addition to his page being huge, there may be other factors at work as well at the moment.

-Robert Rohde

_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Robert: With regard to your Q: “Greg, how often do you worry about more than 10 digits?”, the answer is, ‘not too often.’ The highest- precision set of number sequences on my sandbox is nine significant digits; e.g. 0.298728008

Getting floating-point math to no longer produce rounding errors (like it is a cheap hand-held calculator where 5/3 x 3 = 4.9999998) will likely take away most of the need to have a caveat on WP:MOSNUM about using {val}. Still, it couldn’t properly ever parse a number like 1.2300 and leave the last two zeros in the result.

As for your comment, Robert: “ Though, we may still want to consider building number formatting options into Mediawiki directly since I'm not sure putting all of that formatting effort into template space is really a good idea”, I agree; Mediawiki would be the better place for this. There were a number of editors on WT:MOSNUM who were very enthusiastic over the notion of a character-counting parser function that could treat *anything* as a string of mindless characters and could respond to requests like “gimme three” – “gimme three more” – “and gimme the last four”.

If such a character-dolling parser function has a little bit of extra sophistication (perhaps if combined with other existing functions), then template authors could ask a couple of questions like this about the nature of the string:

“How many characters are to the left of a decimal point?” “How many characters are to the right?”

…and then request the following from a character-dolling function:

“Give me the first three to the right of the decimal point”

As I understand it, adding character-dolling functionality to Mediawiki would be very well received indeed.

Greg

On Feb 2, 2009, at 12:33 PM, Robert Rohde wrote:

On Mon, Feb 2, 2009 at 10:55 AM, greg_l_at_wikipedia greg_l_at_wikipedia@comcast.net wrote:

I have a sandbox with hundreds of test numbers to exercise the {delimitnum} template. This template uses the same math-based functions as {val}. For anyone who has produced improved math functions, you can examine values on this sandbox that currently produce rounding errors and test your new math functions. The sandbox is at the following:

http://en.wikipedia.org/wiki/User:Greg_L/Delimitnum_sandbox

At the very bottom of the page (which loads slowly), is a concise list of values that all have errors.

It would still be much better if a character-counting parser function can be made. Then, numbers like {{val|1.4500}} won't have its two trailing zeros truncated.

Based on feedback, principally from Aryeh, I modified a previous effort to add an explicit fractional tolerance test of 1e-10 to #expr when performing comparisons and integer conversion (e.g. floor, ceil, mod, etc.)

That would have the effect that the comparison functions and integer conversion would generally operate correctly up to 10 significant figures (e.g. A == B if A/B - 1 < 1e-10). This would eliminate many of the problems associated with comparison functions and modular arithmetic, but with the tradeoff that those same operations may give unexpected results if the significand is intended to have more than 10 base-10 digits.

This doesn't apply to basic math operations (+, -, *, ^, etc.) except where they are coupled to either comparisons or integer conversions. So if someone simply wanted to do computations, such as 47.3 * 10.23^7.8, then they will still get all ~15 digits that PHP is capable of displaying.

I see this principally as a step to make the basic math functions more reliable and consistent with user expectation by reducing the impact of floating point rounding effects. An indirect effect is that I believe those number formatting templates would generally work as intended for significands with no more than 10 digits. (Greg, how often do you worry about more than 10 digits?) Though, we may still want to consider building number formatting options into Mediawiki directly since I'm not sure putting all of that formatting effort into template space is really a good idea.

Aryeh and I seem to have a difference of opinion about whether sacrificing precision for some operations involving more than 10 significant digits is an acceptable trade-off for quashing round-off problems most of the rest of the time. The code is in r46683, and I would appreciate some additional viewpoints on this.

Thanks.

-Robert Rohde

_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I’ve seen two three different, pretty-good template authors tackle this issue in {{delimitnum}} and {{val}} and both ran up against the precise same rounding error and struggled mightily with it for a week. I assume that they currently have no other math-based parser functions to avail themselves of to avoid this issue. Is that assumption incorrect?

On Feb 1, 2009, at 6:22 AM, Platonides wrote:

Aryeh Gregor wrote:

The issue is bog-standard floating-point error. If PHP has a decent library for exact-precision arithmetic, we could probably use that. Otherwise, template programmers will have to learn how floating-point numbers work just like all other programmers in the universe.

http://www.php.net/bc

_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Sat, Jan 31, 2009 at 8:33 PM, Robert Rohde rarohde@gmail.com wrote:

This discussion is getting side tracked.

The real complaint here is that

{{#expr:(0.00007 * 1000 * 1000) mod 1000}} is giving 69 when it should give 70.

This is NOT a formatting issue, but rather it is bug in the #expr parser function, presumably caused by some kind of round-off error.

It's a bug in the user's understanding of floating point on computers, combined with % being (quite naturally) an operator on integers.

0.000070000… does not exist in your finite precision base-2 based computer.

I don't think it's reasonable for Mediawiki to include a full radix-n multi-precision floating point library in order to capture the expected your behavior for these cases, any more than it would be reasonable to expect it to contain a full computer algebra system so it could handle manipulations of irrationals precisely.

On Mon, Feb 2, 2009 at 5:42 PM, Greg L greg_l_at_wikipedia@comcast.net wrote:

If so, then we might as well throw up our hands that trying to delimit numbers via math functions is a lost cause.

Right.

I mean— it can be done— you just have to have the computer doing either symbolic manipulation in the right base, or doing effectively infinite precision math. There is software for this. It's complicated and probably doesn't belong in MediaWiki.

Joe random coder who tried to accomplish the same task (delimiting) in the same way (using math on floating point values) via any popular computer language would encounter the same problems.

What you really want, as far as I can tell, is string functions, not math.

Or… really what you want is a full programming language, with its compliment of iteration and string mangling functions, to handle your document formatting. Such a thing can be done safely to some degree or another (as our web-browsers prove), but I'll leave it to someone else to propose it. I'll just sit back and enjoy watching the messenger get stabbed. :)

Let me try that again since I mangled the last response:

Sure. And my expectation that 5 divided by 3 times 3 ought to equal 5 and not 4.9999998 is due to my relative understanding of math and relative lack of understanding regarding the inner workings of common calculators. Is there some downside to fixing rounding errors in math functions? If so, then we might as well throw up our hands that trying to delimit numbers via math functions is a lost cause.

On Feb 2, 2009, at 2:32 PM, Gregory Maxwell wrote:

On Sat, Jan 31, 2009 at 8:33 PM, Robert Rohde rarohde@gmail.com wrote:

This discussion is getting side tracked.

The real complaint here is that

{{#expr:(0.00007 * 1000 * 1000) mod 1000}} is giving 69 when it should give 70.

This is NOT a formatting issue, but rather it is bug in the #expr parser function, presumably caused by some kind of round-off error.

It's a bug in the user's understanding of floating point on computers, combined with % being (quite naturally) an operator on integers.

0.000070000… does not exist in your finite precision base-2 based computer.

I don't think it's reasonable for Mediawiki to include a full radix-n multi-precision floating point library in order to capture the expected your behavior for these cases, any more than it would be reasonable to expect it to contain a full computer algebra system so it could handle manipulations of irrationals precisely.

_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Artur Fijałkowski, Does that mean a template author could selectively apply the round() function on {val} when it is manipulating numbers and doing so would solve its periodic rounding errors? Or would using the round() function possibly introduce errors of its own?

If the latter, I would again suggest that what the template authoring community could really use are just two character-string-manipulating functions:

1) The first would be a function that you could tell to go fetch the string fragment to the right of a specified character, like a decimal point (and the same to the left of the decimal point). 2) The second function would could count how many characters are in the returned strings.

With those two, simple parser functions, template authors could have a field day. With {val}, it could now be told, “there are 10 characters to the right of the decimal point” and the template could calculate that it must delimit in two groups of three and a final group of four digits (e.g. 0.123 456 7890). Then, as I understand it, there is already a “character cannon” of sorts {{#sub:mystring|0|3}} that can feed out the characters.

The virtue of this approach is a character-based version of val could handle numbers bigger than ten digits (an increasingly necessary feature since physics is now more frequently establishing physical and universal constants at precisions of 11 or more significant digits). Also, {val} would be able to handle numbers that end with zeros, such as 2.4500.

Greg

On Feb 8, 2009, at 2:17 AM, Artur Fijałkowski wrote:

2009/2/2 Greg L greg_l_at_wikipedia@comcast.net:

Let me try that again since I mangled the last response:

Sure. And my expectation that 5 divided by 3 times 3 ought to equal 5 and not 4.9999998 is due to my relative understanding of math and relative lack of understanding regarding the inner workings of common calculators. Is there some downside to fixing rounding errors in math functions? If so, then we might as well throw up our hands that trying to delimit numbers via math functions is a lost cause.

It's not a rounding error, but effect of finite-length binary representation. If you 'fix' floating point arithmetic in way that 4.9999998 will be 5 you will fuck all other computations in which it will be precise result.

If you really want to see such thing always use round() function ;)

You should remember that probably many compilers will simplyfy expression '5/3*3' into '5' :)

AJF/WarX

_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Feb 2, 2009, at 2:56 PM, Robert Rohde wrote:

On Mon, Feb 2, 2009 at 2:32 PM, Gregory Maxwell gmaxwell@gmail.com wrote:

On Sat, Jan 31, 2009 at 8:33 PM, Robert Rohde rarohde@gmail.com wrote:

...

This discussion is getting side tracked.

The real complaint here is that

{{#expr:(0.00007 * 1000 * 1000) mod 1000}} is giving 69 when it should give 70.

This is NOT a formatting issue, but rather it is bug in the #expr parser function, presumably caused by some kind of round-off error.

It's a bug in the user's understanding of floating point on computers, combined with % being (quite naturally) an operator on integers.

0.000070000… does not exist in your finite precision base-2 based computer.

I don't think it's reasonable for Mediawiki to include a full radix-n multi-precision floating point library in order to capture the expected your behavior for these cases, any more than it would be reasonable to expect it to contain a full computer algebra system so it could handle manipulations of irrationals precisely.

I've already written code that converts 4.9999999998 to 5 immediately before performing operations that explicitly expect integers by applying an explicit 1 part in 10^10 tolerance. That covers a wide range of cases that might be affected by round-off errors while adding little overhead.

-Robert Rohde

That sounds good to me, Robert. Could there be any downside to this? Can the concept be tried on the contents of my sandbox without messing with Wikipedia-proper? -Greg

_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Focusing on a key assumption of yours, Gregory: “Adding a number fudging kludge to produce a less accurate result…”

Is this true? It seems that Robert Rohde is suggesting that his code turns round-off errors back to their intended values. Is your assumption true that this tweak MUST necessarily also occasionally fudge up correct results into incorrect ones?

That said, I agree also with your last paragraph: string functions is the best solution for {val}, since it will allow it to render output with trailing zeros, such as 2.4500(15) x 10^16

Greg

On Feb 2, 2009, at 3:25 PM, Gregory Maxwell wrote:

On Mon, Feb 2, 2009 at 5:56 PM, Robert Rohde rarohde@gmail.com wrote:

I've already written code that converts 4.9999999998 to 5 immediately before performing operations that explicitly expect integers by applying an explicit 1 part in 10^10 tolerance. That covers a wide range of cases that might be affected by round-off errors while adding little overhead.

I can't wait to see the complaints when some compiler upgrade results in the code using the 32bit SSE registers rather than the 80bit FPU and producing inexplicably different results.

The whole reason that the discussion is even being had here is because Wikipedia is full of pedants. Adding a number fudging kludge to produce a less accurate result to order to fix some other kludge, just to satisfy one set of pedants is only going to irritate another set of pedants later.

Doing math in the parser is the wrong solution for this. Give the users string manipulation functions and save the math for integer only calculations and sausage making like table layout. Finite precision math simply can't be guaranteed to produce reasonable results for non-integer "content math" purpose.

_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

2009/2/3 Robert Rohde rarohde@gmail.com:

My code assumes floor( 4.9999999999 ) should really be floor(5) = 5.

If someone really expects floor( 4.9999999999 ) to be 4, then from their point of view that is an error.

If anyone want to be sure that floor(4.99999999..) == 5 he should use floor(round()) not floor().

AJF/WarX

How long would it take a good coder to write a bullet-proof character- cannon? Also…

Do I assume correctly that there are already parser functions available that template authors can use in order to take a numeric value between two pipes; e.g. “1.1234567”, and count the digits to the left of the decimal point (the integer portion of the significand), count the digits to the right of the decimal point (the fractional portion), and separate off the fractional portion in preparation for sending it to a character cannon? Is that right?

On Feb 3, 2009, at 9:40 AM, Aryeh Gregor wrote:

On Tue, Feb 3, 2009 at 12:38 PM, Artur Fijałkowski wiki.warx@gmail.com wrote:

If anyone want to be sure that floor(4.99999999..) == 5 he should use floor(round()) not floor().

That defeats the point of using floor(). It would turn 4.6 into 5 also. In fact, floor(round(x)) is exactly the same thing as round(x).

_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Tue, Feb 3, 2009 at 1:34 PM, Andrew Garrett andrew@epstone.net wrote:

About ten minutes. The question is not one of developer time, but one of whether we actually want a "character-cannon" (I'm not quite clear on what that is, but I'm assuming it's a string-functions expansion of wikitext), and what its implications are for performance and usability.

Usability in editing meta-templates has been a lost cause since few years ago with the introduction of {{qif}}. I very much doubt anyone other than a programmer could edit meta-templates easily without spending weeks fidgeting with them first. Adding string functions couldn't possibly *reduce* this level of usability significantly.

I very much doubt that performance would be any kind of issue either. We're talking about exposing a few low-level functions implemented in C, with execution of the function itself bounded to fractions of microseconds (probably much less than transcluding a single template). This is as opposed to right now, where the absence of such functions often causes workarounds to be implemented using giant switch statements or lengthy sequences of ifs.

The only credible argument I can see against StringFunctions (or similar) is that we should be replacing wikitext with a real programming language. Until that happens -- and it doesn't look likely to happen soon -- it could only be helpful to provide some more efficient and easier-to-use basic programming constructs.

Someone needs to read a good WP article before they start mentioning (X)HTML version numbers: http://en.wikipedia.org/wiki/XHTML

HTML5 and XHTML5, called HTML5 as a general but like HTML4 and XHTML1.x they are basically the same API with different tag parsing flavors. You don't need to drop from XHTML into HTML to get v5 support. As for XHTML2. Don't make the mistake of thinking that because XHTML was v1 they're going to use sane numbers and move up to HTML5 and XHTML2 because the previous names were HTML4 and XHTML1. Nope, instead they've made numbers parallel and the successors to HTML4 and XHTML1 are HTML5 and XHTML5.

XHTML2 is a completely different specification which is not backwards compatible with old XHTML1 documents. Though it does look interesting, going from a XHTML <a href="http://example.com"><img src="img.png" alt="alt text" /></a> ^_^ and instead using <img src="img.png" href="http://example.com">Alt text <em>With Emphasis!</em></img>, heh.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com] -Nadir-Point (http://nadir-point.com) -Wiki-Tools (http://wiki-tools.com) -MonkeyScript (http://monkeyscript.nadir-point.com) -Animepedia (http://anime.wikia.com) -Narutopedia (http://naruto.wikia.com) -Soul Eater Wiki (http://souleater.wikia.com)

Platonides wrote:

Aryeh Gregor wrote:

...

On Sat, Jan 31, 2009 at 4:23 PM, jidanni@jidanni.org wrote:

...

Gentlemen, In wikitext I want to do <ol start="6101">

<li>a <li>b </ol> but http://www.w3.org/TR/html401/struct/lists.html says that is deprecated.

It's been un-deprecated in HTML5, for what that's worth. I don't know whether XHTML2 has done so as well.

IMHO it should be allowed to do

<ol start="6101"> # a # b </ol>

instead of having to revert to html to do this -otherwise not too uncommon- action.

(X)HTML5 is the accepted successor to (X)HTML [HTML4/XHTML1.x] XHTML2 is a branch standard of XHTML (there is no HTML equiv to it) with different goals, purposes, and isn't even widely implemented enough to be considered something viable for use. It's unlikely many browser vendors are even going to implement support for it. But it is afact that something called XHTML2 exists and it has nothing to do with HTML5. I'm just piping up against the misnomer of using the name "XHTML2" when you are actually referring to "XHTML5".

Though on the note... as I believe when it comes to it the doctype and what kind of stuff you use/the browser uses have little to do with each other. Using an old (X)HTML doctype, I believe browsers that support it will still make use of the <canvas /> element even though you're /supposed/ to use a (X)HTML5 doctype. The DOCTYPE merely controls validation, and what browsers you want in quirksmode, almost-standards, or standards mode. It might control parsing a little, but to be honest the content-type is really the only thing that at least Firefox considers for that. Even using a XHTML doctype Firefox still parses your document using loose HTML rules. It doesn't parse it with an XML parser unless you use application/xhtml+xml.

To be honest I've been on the personal debate lately on whether XHTML is really viable. Or if it's better to just have my applications start spitting out clean HTML with a HTML doctype rather than using XHTML. Most browsers don't bother with the XML factor of XHTML, the fancy parts of XHTML (like inline svg or more importantly, your own custom namespaces) aren't widely supported enough, CSS can't style namespaced nodes (Except in IE, which is strange because IE is the single browser that makes the whole XHTML as XML factor lag), using an actual XML generator to output your XHTML pages can cause invalid pages to be outputted (script tags may likely be outputted as <script src="..."/> which breaks in all browsers except FF2 (FF3 purposefully makes that break for it now), and an empty span as <span/> which can cause issues when the browser doesn't parse the document using pure XML), and it's actually fairly trivial to take a generated XML document and modify it to be HTML.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com] -Nadir-Point (http://nadir-point.com) -Wiki-Tools (http://wiki-tools.com) -MonkeyScript (http://monkeyscript.nadir-point.com) -Animepedia (http://anime.wikia.com) -Narutopedia (http://naruto.wikia.com) -Soul Eater Wiki (http://souleater.wikia.com)

Aryeh Gregor wrote:

On Sat, Jan 31, 2009 at 10:12 PM, Daniel Friesen dan_the_man@telus.net wrote:

...

Someone needs to read a good WP article before they start mentioning (X)HTML version numbers: http://en.wikipedia.org/wiki/XHTML

Both HTML5 and XHTML2 are successors to HTML4. That's all that's really relevant here. HTML5 has un-deprecated the "start" attribute of <ol>, so nobody should be worrying about HTML4's deprecation of it. (XHTML2 does appear to have removed the attribute, so I guess you could worry about it if you plan to move to XHTML2 in the future. But probably nobody is going to use XHTML2, and MediaWiki almost certainly isn't.)

...

...

...

...

"AG" == Aryeh Gregor Simetrical+wikilist@gmail.com writes:

AG> Just to get this back on-topic: basically, the <ol start=6101> method AG> is the correct one, and you should use that. Ignore HTML4's AG> deprecation of the attribute. OK, it's a deal. But is there any way to combine that with the convenience of "#"?: #How can I jump start this line to 6100 without resorting to <li>?