Re: XHTML 2.0 considered harmful

Tantek Çelik wrote:
> On 1/14/03 3:56 AM, "Christoph Päper" <christoph.paeper@tu-clausthal.de>
> wrote:
>>Tantek Çelik:
> 
> I too prefer <L> over <BR>, but why not just keep <BR> and deprecate it?
> Similarly, add <H>,<SECTION> and deprecate <H1>...<H6>?
> And simply deprecate <IMG>.

There's no need to deprecate elements in XHTML2 because it isn't 
backwards compatible. As always, the latest recommendation should be 
followed while doing new pages--nobody expects that all the existing 
pages are fixed to follow latest spec. The more simple the basic XHTML2 
is, the better.

I understand that old authors may feel a bit lost when they meet XHTML2, 
but it's more important that the language is as simple as possible to 
learn for new authors. Majority of the pages in the web today 
demonstrates that those old authors didn't follow the older specs either 
so it shouldn't make any difference what the new spec says. Majority of 
the web isn't going to magically upgrade to XHTML2 (or any other XML 
format and/or structure format) in any time soon. IMO, the biggest 
problems in HTML are br, hr, img and all form elements. XHTML2 can fix 
all of those.

Ever wondered why almost everybody still marks stuff bold and italics 
when they /really/ mean strongly emphasized and emphasized. (By the way, 
I think that strong should be removed; we can use nested em's instead.) 
It's because most page authors don't know the difference between 
different rendering and different sematics. "If it looks the same with 
both elements then either one must be correct."


> examples.  The lobbying to use cumbersome XLink syntax in an end user
> document format is another.  "not backwards compatible" has become the most
> abused cop-out for bad design in XHTML2.0.

I don't like XLink syntax either. Just keep "object", "link" and "a" 
elements and majority of external linking can be handled like today. For 
pretty much everything else, HLink <URL:http://www.w3.org/TR/hlink/> 
looks promising.


>>>[2] XHTML2.0 dumps harmless elements which folks have found
>>>semantically useful.
>>
>>Which (except cite)? IMHO it's right to drop unneeded elements even if
>>they're "harmless".
> 
> It's harmful to drop harmless elements.  At a minimum it makes sense to
> deprecate them first.

It might depend on how one defines "harmful"... For example, I consider 
H1-H6 harmful because they allow incorrect structure (one could start 
structure at level 2 instead of level 1). Also, stuff like br, hr and 
style attribute are strictly presentational and therefore harmful.

Stuff that has only sematics but that isn't used that much (like cite) 
should stay. It might be marked deprecated but if people start using 
them it should be brought back to the "official" set.


>>>It also dumps the extremely useful 'style' attribute
>>
>>Except for quick-n-dirty CSS test suites I can't see any use for it.
>>It's
>>fully replacable by id + CSS, too.
> 
> Only superficially.  Using id does not actually capture the full
> capabilities of the 'style' attribute.

Please, provide and example (real world or made up) that demonstrates a 
case where style attribute could be considered a better way to solve the 
problem than simply using id + CSS.

And some stupid corporation that uses site-wide CSS stylesheet that 
cannot be fixed isn't a valid reason to include style attribute. It's 
just like we don't drop the requirement for well-formed XML simply 
because some 3rd party software is broken and cannot produce valid 
documents. Even if that piece of software were widely used... I think 
standards should be about making the right thing in a long run, instead 
of doing what current technology allows immediatly. (A good example of 
designing for current technology instead of for future is WAP 1.x. 
Notice how they change *everything* for WAP 2.x.)

In my experience, the style attribute is way too often used to "fix" 
incorrect markup.

-- 
Mikko

Received on Tuesday, 14 January 2003 11:32:10 UTC