W3C home > Mailing lists > Public > public-html@w3.org > May 2007

Re: brainstorm: attributes as virtual tags

From: Dmitry Turin <html60@narod.ru>
Date: Fri, 18 May 2007 15:58:11 +0300
Message-ID: <14525067906.20070518155811@narod.ru>
To: public-html@w3.org

Good day, Dao.
Excuse me for a long break.

DG> <style>
DG>    a::before {
DG>      content: attr(a1) "\A" attr(a2) "\A" attr(a3) "\A" attr(a4);
DG>    }
DG> </style>

<style>
   record1::before { content: attr(name) attr(surname) }
   record2::before { content: attr(name) attr(surname) }
</style>
<body>
  <record1 name= surname= >
  <record2 name= surname= >
</body>

    This way don't allow to specify styles for visualization of these attributes
(like the following)

<style>
  record1 §name, §surname {color: red  }
  record2 §name, §surname {color: gray }
</style>
<body>
  <record1 name= surname= >
  <record2 name= surname= >
</body>
</style>

  So we see, that michanism of property "content" is _essentially_ narrower,
than michanism of virtual tags. Virtual tag allow to use even pseudo-classes.
  I don't want to reduce importance of property "content":
it is necessary to change already existing content of html-element,
or to specify content of pseudo-element.
But when you try to reduce all cases to property "content", property acts as limiter,
and thus data are subdivided into two groups depending on their forms:
if data is between an open and close tags, it is data _of full value_ (it may has style);
if data is in an attribute, it is _inferior_.

  It's not reasonable to abandon virtual tags,
only because more weak decision was already thought up.

P.S.
Other example

<style>
  tab  { display: table      }
  a    { display: table-row  }
  a §* { display: table-cell }
</style>
<body>
<tab>
  <a a1="v11" a2="v12" a3="v13">
  <a a1="v21" a2="v22" a3="v23">
  <a a1="v31" a2="v32" a3="v33">
</tab>
</body>



Dmitry Turin
http://html6.by.ru
http://sql4.by.ru
http://computer2.by.ru
Received on Friday, 18 May 2007 12:58:30 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:44 UTC