Re: XBL is (mostly) W3C redundant, and CSS is wrong W3C layer for semantic behavior *markup*

John,

I will not respond to Ian (because our debate was non productive), but I
will respond to others as long as our discussion is productive and not
redundant.


At 07:24 AM 1/3/2003 -0600, John Lewis wrote:
>> Notice that this definition of semantics is very broad. It does not
>> differentiate the the semantics of a header from the opening
>> sentence of a paragraph. Both "briefly describes the topic of the
>> section it introduces"
>
>> Thus some of the important semantics of header, as different from
>> first sentence of paragraph, are open to interpretation.
>
>> Some parsers might ignore the headers entirely and merge them as
>> first sentence of first paragraph.
>
>CSS can do that by changing the display value of a header to "run-in".
>That doesn't change the definition of header elements, it simply
>changes their *appearance*. Changing the display value of all headers
>to "none" does not mean header elements have no meaning. They still
>have meaning as defined in HTML--they're just not presented to the
>user.


I agree.  And you have to deleted the part of my response wherein I said
the header was a "weak" example on my part and that "nevertheless it
doesn't change the fact that XBL" can support new tags and thus give them
meaning by implementing them for the first time.


>
><http://www.w3.org/TR/REC-CSS2/visuren.html#run-in>
>
>I think you're confusing semantics as defined by HTML with semantics
>as interepreted by a reader. For example, using CSS, I could change
>the display value (and other values) of nearly every tag in HTML so
>that to the reader, <em> is a header, <h1> is a paragraph, and
><strong> is a blockquote. That does not and cannot change the meaning
>of those elements as defined in HTML, even though it would fool the
>average reader with CSS enabled.


I am not confusing rendering and semantics.  I understand that the header
example was "weak" one in "grey" area between semantics and presentation.
And realize that you deleted the part of my response where I said that
displaying multiple headers where only one was marked up, is to some degree
changing the markup layer from one-to-one to a one-to-many mapping.
Whether that is semantic or presentation mapping is debatable.  I am
willing to agree it is presentation and is okay to be in the presentation
layer.  I do think it also has an equal chance to be viewed as an inferred
semantic, similar to how ::first-line is an inferred semantic.

As I wrote in my previous response, none of this changes the fact that XBL
can fully implement a new tag, which is imo very closely related to
semantic interpretation.  If a new tag has no implementation, and you
implement it for the first time, then I think you are essentially providing
its semantics for the first time.

The logical extension from that is that if you are creating a new tag, then
any specification for that tag is very likely only understood by a very
small audience initially.  Thus the content of the implementation (which is
semantic markup in XBL using the "content" syntax) is really the semantics,
because that content contains tags that are understood by a wide audience.

Thus the semantics of the implementation of a new custom tag is more
practically defined by it's implementation than by any new specification,
until and unless the specification becomes widely used/known.  Thus when
implementing new tags by using supported markup, that is primary a semantic
function and should be in the semantic layer before parsing.

More below...


>> That is totally different than changing the rendering such as font
>> of a header. One is semantically significant, and the other is
>> merely presentation property. This is a grey area, and especially
>> the header is a poor example to analyze because it is so broad.
>
>Could you prove, or at least explain, how changing the display value
>of an element is "semantically significant"?


As I said above, the header example was not a strong one.

Let's focus on the new tag example.  It is less debatable.

More below...


>>>>>> Shelby Moore wrote:
>>>>>> CSS selectors allows one to select elements of markup based on 
>>>>>> attributes which are not related to *semantics*.
>>>>>
>>>>> Ian Hickson responded:
>>>>> As an editor of the W3C Selectors Specification, I assure you,
>>>>> that is most definitely not the intention of CSS selectors. 
>>>>  
>>>> Ian's "assurance" was false.
>>>
>>> There are no attributes that are not related to semantics, since
>>> attributes are part of an element's meaning.
>
>> False. Font can be set on a paragraph and font has nothing to do
>> with the semantics of paragraph. This is 3rd time I have mentioned
>> that font is not semantically related to paragraph.
>
>> John Lewis has written in this thread "CSS doesn't need to know the
>> markup languages it's applied to, or any markup language at all;
>> that's the beauty of it. Knowledge of the markup language's elements
>> is contained in the CSS author, where it belongs.".
>
>> John Lewis also restated in another way, "CSS selectors match
>> elements without regard to the elements' semantics"
>
>Attributes are not selectors. I agree with your "Font can be set on a
>paragraph," etc., but I also agree with Ian's original reply.


Grammatically my sentence means that the attributes used to "select".  Use
any grammatical reference for English language.  Those would be the "class"
attribute of a markup element.

"CSS selectors allows one to select elements of markup based on attributes
which are not related to *semantics*."

You and Ian were apparently confusing this with CSS attributes.  In any
case, I explained that even CSS attributes (e.g. font of paragraph) do not
deal with semantics.  So in either interpretation, my statement was correct
and Ian was wrong.



>>> Absolutely, just as CSS can style tags [sic] that have no
>>> specification. That doesn't mean those elements suddenly gain some
>>> sort of meaning.
>
>> CSS is not and should not be involved in providing meaning. That is
>> my point.
>
>Agreed. In fact, CSS cannot provide, change, or erase meaning, which
>means changing display values cannot change meaning. 


I agree.


>I don't think Ian
>disagrees.

Afaics, Ian seems to think that the only semantics come from specification
and that thus it is okay to spread out the parsing to any layer without
endangering the separation between semantics and presentation.  I think
this why he refused to draw a bi-directional line between XBL and
"Semantics" layer in his layer diagram (posted somewhere in this thread).
As I explained above, when implementing a new tag, this hard rule begins to
fall apart, because specification is just an argument.  What is actually
understood by the world (interpretation), is the actual practical
semantics.  Read on before judging my statement...

For example, you could specify that header go at top (before) of section it
summarizes.  But if the majority of the world always presented it below,
then the specification would be overruled by the world.  Thus when
implementing a new tag for the first time, the semantic markup used in the
implementation is much more likely to represent the useful semantics than
any new specification that might exist.  I am talking about a new tag made
by a small entity.  Of course if the W3C made a new tag, then it has the
clout to insure it's specifications are more normative than the
implementations.  W3C specifications tend to be normative in reality.  But
this is not guaranteed.  The W3C must be careful to continue to make
correct/optimal standards and specifications.

We are after all living in a real world.  Ivory towers of specification at
the end of the day do not determine reality.  Only the clout and reputation
of the W3C determines whether it specifications are normative in practice.

I suggest you refer to my example where I show that XBL hides/obscures
(makes "anonymous") the normative "content" semantic markup when
implementing new tags:

http://lists.w3.org/Archives/Public/www-style/2003Jan/0049.html


And regarding the importance of separation between semantics and
presentation, I will insert something my co-worker emailed me about this
thread:


>Tony wrote:
>I have been studying a little about SGML.
>
>Seems to me that SGML is the mother/mind of markup languages, and defines
>them.
>
>Interesting, in that XBL tends to violate some basic principles of
>SGML.
>
>"Unlike other common document file formats that represent both
>content and presentation, SGML represents a document's content
>data and structure (interrelationships among the data).
>Removing the presentation from content establishes a neutral
>format. SGML documents and the information in them can easily
>be re-used by publishing and non-publishing applications."
>
>"Reuse - separation of content from presentation facilitates
>multiple delivery formats like CD-ROM and electronic
>publishing"  
>
>*and Applications!*
>
>"SGML identifies document elements such as titles, paragraphs,
>tables, and chapters as distinct objects, allowing users to
>define the relationships between the objects for structuring
>data in documents. The relationships between document
>elements are defined in a Document Type Definition (DTD)."
>
>
>"Since 1998, almost all development in SGML has been focussed
>on XML - a simple (and therefore easier to understand and
>implement) subset of SGML."
>
>
>http://dictionary.reference.com/search?q=standard%20generalized%20markup%20
language


-Shelby Moore

Received on Friday, 3 January 2003 10:58:53 UTC