<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 <[email protected]>
To: River John <[email protected]> 
Cc: [email protected] 
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/

Reply via email to