W3C home > Mailing lists > Public > www-style@w3.org > July 2007

Re: unite two space: attributes and properties

From: Dmitry Turin <sql40@narod.ru>
Date: Wed, 18 Jul 2007 10:38:20 +0300
Message-ID: <37876188.20070718103820@narod.ru>
To: www-style@w3.org

DW> What you are proposing appears to be a fundamental breach of the
DW> principle that content and presentation are separated in CSS.
Two arguments are still not brought:
(1) why not presentational attributes should not be specified in CSS-file
(2) why presentational properties should not be specified without @style
_while_ they will being specified in tags.

  #1 (if is assertion) is wrong essencially,
because now CSS is _bracket_ for any features
(recall about binding, aural style, behaviour).
  As to #2, i see only one argument: to use style= as syntax bracket.

>> Source of document is cluttered up by superfluous attribute @style,
DW> it is really a last resort,
DW> with, in increasing order of preference, id based selectors, and general
DW> rules, being preferred.
  I prefer TAG#id in CSS than @style in TAG itself
(because i like separations).
But sometimes @id as gasket and running between content of enclosed elements and
CSS is not convenient.

---

DW> Most presentational attributes [...] and if there are some
DW> that still can only be implemented with HTML
Some presentational features can be implemented only as attributes?
I don't know principle restriction.
List them.

EF> There are examples where table attributes cannot be
EF> mapped into CSS; however, this is not one of them.
Bring these examples, what will allow to understand question deeply.

-------

EF> Is there something wrong with the CSS border-spacing
EF> property?
Solving of particular case of problem does not decide problem in general.



Dmitry Turin
HTML6     (6.1.2)  http://html60.chat.ru
SQL4      (4.1.2)  http://sql40.chat.ru
Unicode2  (2.0.0)  http://unicode2.chat.ru
Computer2 (2.0.3)  http://computer20.chat.ru
Received on Wednesday, 18 July 2007 12:46:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:51 GMT