Re: Some advices for table, th and td elements

<xml version="1.0">

<rant tone="impatient, but enthusiastic">


An interesting response. The "presentational" argument is, in my opinion, weak at best. HTML is presentational in nature. If you don't want presentation, then use XML. If presentation wasn't a key feature of HTML, we'd all still be using gopher and LaTeX. I do appreciate the distinction between data and view, I do. But that's not what HTML is about, its what XML is about. The presentation argument would have us using XML with a XML style sheet, which would be a duplication of standards. Why do we need a XML version and a HTML version of the same thing?


Of course my opinion is also shaped on how CSS sucks so very much. CSS doesn't really "cascade" the way it should. It really should support OOP style inheritance. Because of this design flaw of the standard I have classes that output a CSS file using proper inheritance. And I think a lot of people do the same thing. To me, that means the spec is off-target. The other major design flaw is the CSS markup should be using XML as well, so we don't need multiple parsing technologies. But that would get us back to using XSL. And when things converge like that, it's generally a good idea.


This patchwork of technologies is comical at best. How many syntaxes are we going to have to learn to develop a web page? I am very disappointed at the whole patchwork of technologies that is web development. It increases software complexity immensely, and as a software developer I am aiming for the nirvana where we have the computers do all the heavy lifting, and that system should be around one technology - XML. Supporting different syntaxes tremendously increases the development and testing efforts - at first with many parsing libraries, then overall because these technologies are versioned independently, so one upgrade at one end of the processing pipeline (some developer moved to CSS3) upsets everything else. XML has been exceedingly stable. If we are to realize Tim Burners-Lee's vision of linked data, then we have to standardize even further.

</rant>

<suggestions>
<immediate>1. Keep the attributes</immediate>
<future>

2. Move CSS to XSL. Compile existing CSS to XSL, so existing web devs can instantly migrate. Deprecate CSS.
3. Drop HTML entirely, use only XML and XSL. Provide a decompiler that will take HTML and split it up into XML and XSL components.

</future>

</suggestions>




________________________________
 From: Jukka K. Korpela <jukka.k.korpela@kolumbus.fi>
To: River John <r0011cn@gmail.com> 
Cc: public-html-comments@w3.org 
Sent: Thursday, July 12, 2012 4:48 AM
Subject: Re: Some advices for table, th and td elements
 
2012-07-11 12:49, River John wrote:
> I think that the "width" attribute for td, th and table elements is very useful, and should not be as the attributes that will "Not supported in HTML5".

It is presentational, and the policy is to declare such attribute as obsolete, see
http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#presentational-markup,

Not everyone agrees with this ideology - and none of the reasons listed in the cited document really applies to the case you describe, or many other cases -, but I think it's unrealistic to try to change it now, unless you can come up with *very* strong arguments about some special cases.

Note that the attribute is declared obsolete but still to remain in the spec, with description of its meaning, and browsers are required to support it, and will undoubtedly do so; see
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#conformance-classes

The only real problem, to people who wish to keep using presentational attributes, is that conformance checkers will issue error messages. This can make it more difficult to distinguish real errors from a long list of messages. But I suppose someone will some day create a conformance checker that has the option of switching off the "ideological" messages.The benefits to do this:
> 
> 1. We can specify the width of columns in a table immediately and simply.
> 
> 2. Need not write CSS for each table and each column.
> 
> 3. Need not add the class attributes to these elements in order to applying the CSS
> 
> 
Considering some old browsers, it is true that class attributes would be needed in some situations, but nowadays support to selectors like :nth-child(...) are rather widespread. You may still need to use id or class attributes for <table> elements to have different styling for different tables, unless you prefer using style="..." attributes.

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