 |
 |
 |
That's the well-known impedance mismatch with objects: attributes are not
OOP fields. No matter how it is explained away, some want atts to have
structure and that is the same as saying they might as well-be subtrees (the
Xerox solution from way before XML or HTML).
It's fun to play what-if in a historical mode, but there isn't much chance
of a change here. The alternative is to get the CSS out-of-line but the
implementations for this and other things att values are used for has
possibly gone too far for too long.
I do remember the CSS vs markup syntax discussions, but didn't want to
comment publicly. The outcomes are what they are and having seen what
markup looks like in graphics, my mind changed. Sometimes pointies are the
wrong way to go for aesthetics.
len
From: Thomas Lord [mailto:lord@e...]
Len Bullard wrote:
> The problem of having values in attributes would still exist.
I was vaguely imagining that CSS attributes would become
element attributes in isolated namespaces, so, no problem.
What is currently a single attribute in HTML would get bust
out into several attributes in HTML. (This is not to say that
moving away from the current CSS syntax in browsers and as
used in HTML is practical. Just how it might be if history had
happened in a slightly different order or how it might look if
the current situation can be sealed off like a blowed up reactor
and covered over with clean new standards and translators in between.)
> A follow on
> question might be is the use of microformats and other values in
attributes
> such as scripts a sound use of XML attribute value-pairs.
>
You're asking the wrong guy, partly. I have (unsurprising and
probably somewhat shared) views on what's practical and appropriate
in that area but, in the bigger picture, I think the limitation of
XML attribute values to be strings is a mistake: attribute values
which are arbitrary elements should be permitted, in my view.
QNames for element names and attribute names I can see -- you
want values with a fast equality test and namespaces for those
things. Attribute values, however, should be less constrained.
-t
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
|
 | 

|  |
These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.
|  |
| |
 |
 |
 |