- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Mon, 28 Nov 2005 10:04:57 -0500
- To: shelby@coolpage.com
- CC: www-style@w3.org
Shelby Moore wrote:
> Matthew Raymond wrote:
>>...It sounds like you're saying that the <select>, when bound, is
>>receiving "semantics" from the <option> bindings.
>
> If the markup tells the <select> that it is operating on specific data
> types, then the <select> knows (has additional semantic information) about
> what it is selecting.
What data type? Part of the Semantic Web is being able to identify the
nature of the data. Having "country" in a class name is, in fact, not a
data type but and HTML class name. It's only via a specified microformat
that this can be interpreted as a data type declaration.
> Your misunderstanding may be due to that I used the word "bound" meaning
> "confined", not past tense of "bind". Poor word choice on my part
> (actually realized after I sent it).
>
>>I would argue that there are no semantics in the binding,
>
> Correct, no additional semantics in the binding for in the _first_ example
> I gave. The semantics are explicit on the contain children of <select>,
> but it doesn't diminish the architecture's ability to bind semantic
> changes. I repeat the example for clarity.
>
> <style>select { bind SmartDataSelect.xml }</style>
> <select>
> <option class='city'>Shanghai</option>
> <option class='country'>China</option>
> <option class='longitude'>119.9843</option>
> </select>
I don't see the issue. For a UI widget that is specifically designed
to handle multiple implied data types, that is desirable. Otherwise, the
<select> may have problems accommodating the XBL presentation and
behavior of the <option> element.
>> Well, ignoring the obvious pointlessness of having unrelated items
>>types in the same <select>,
>
> Not pointless. A select could display and select from multiple data
> types. For example, a location finder could allow user to select by city,
> counry, or zipcode, etc.., all from one <select>.
While the type of options in a <select> can be just about anything,
all the options in a <select> are typically all of the same type, not
several different types. One does not select from cities, countries and
zip codes for the same field. You have separate fields for all three.
Therefore, it makes more sense to specify the type on the select.
>> If you mean that the bound code can perform "general processing" on
>>the |class| values, then yes. Furthermore, if there is no binding, you
>>have a nice <select> to fall back on.
>
> Yup. Also it could be "enumerated processing".
I was specifically (mis)quoting the HTML 4.01 specification.
http://www.w3.org/TR/html4/struct/global.html#id-and-class
| For general purpose processing by user agents (e.g. for identifying
| fields when extracting data from HTML pages into a database,
| translating HTML documents into other formats, etc.).
I have no idea what you're referring to by "enumerated processing",
though.
>>you've pretty much stated
>>that the code/markup/styling is, in fact, not obscured. Rather, it is
>>simple a little harder to process.
>
> Read:
>
> http://lists.w3.org/Archives/Public/www-style/2005Nov/0157.html
"Because of interoperability, semantic markup and style markup are not
supposed to require each other, i.e. they are orthogonal layers."
There is no requirement. Both CSS and XBL support are optional. You
could argue that they can be specifically used in a way that creates a
dependence for the user, but the same argument can be made for Javascript.
>>You have the whole concept of semantic markup backwards, though.
>>Semantics are what the element mean in a general sense, while the
>>possible implementations of the element can be infinite so long as they
>>don't violate the general meaning of the element. For example,...
>
> I will try to get you to understand your error, by asking you rhetorical
> questions.
>
> What information is lost from markup if we remove the class="..."
> attributes from my example above?
One look at hCard or hCalendar, and you already know the answer is
yes. It's vital to the existence of microformats. However, as I pointed
out above, that is because the |id| and |class| attributes can be used
for "general purpose processing". The semantics come from
mutually-agreed-upon meanings for specific class names. Otherwise, they
only have meaning to the document author (assuming they weren't just
autogenerated by an HTML editor to begin with).
> Look at another way. If you present unspecified data types as "monsters"
> then how did you know they were monsters? How do you map "China" to a
> monster? How do you map "bgvh4676tvvs" to anything? P.S. Don't confuse
> this will the "mapping" I refer to in my linked post above.
What about any UI implementation via XBL would tell you what a
"monster" is? This is what microformats are for. They allow you
standardization of attribute values so that they have agreed upon
semantics that can be processed by a user agent.
>> Another user agent implementation could be to intelligently display
>>the <select> as a map of the world if the |class| attributes for all the
>><option> elements is "country",
>
> Thus semantics of data type are important.
What data type? Class name != data type. A person can be interpret
the class name as identifying the data type, but the only way to know
the semantics for certain is if there's a microformat to support it.
>>or if all of the values are recognized
>>country names.
>
> Imagine all the A.I. we would need just to detect some semantics from
> anonymous content, not to mention the near impossible scenarios. Hint:
> that is why we use tags and tag attributes.
It's not as difficult as you might think. There are a finite number
of countries. If the UA has a list of them, it can compare the <option>
values and determine if they're all in the list. If they are all in the
list, then you can assume it's a <select> for countries. Zip codes and
phone numbers can be checked using pattern matching. Granted, some kinds
of data are more common than others, but that doesn't mean that common
data types can't be detected by the user agent, especially if you have
some obvious title like "Country", "City" or "Longitude" as the contents
of a <label>. Never assume that you're smarter that every programmer on
planet Earth.
>>Now suppose I create a binding that will do the exact
>>same thing. On our theoretical user agent, the behavior and presentation
>>of the <select> is identical. Yet we can't say that the user agent
>>changed the semantics of <select>, because if you do then every user
>>agent assigns a different semantic value to <select> simply by having
>>default rendering and behavior for the element.
>
> Distinguish between rendering and semantic input. The input knowledge is
> that the data types are countries.
It's not knowledge. It's a string. A single class attribute, if that,
since XBL via CSS can bind to any possible selector. While class names
may provide semantics, bindings do not. Hence the term "Shadow Tree":
http://www.mozilla.org/projects/xbl/xbl2.html#shadow5
| The shadow tree for a bound element is the subtree of nodes that are
| attached to a bound element as a result of XBL processing. (See:
| shadow content.) The contents of the shadow tree augment the bound
| element's standard presentation and interactive behaviour with
| alternate behaviour. The shadow tree is hidden from normal DOM
| processing (hence the name "shadow"). The shadow tree is attached to
| the bound element. Once attached, the shadow tree can be accessed only
| via XBL-specific DOM extensions and therefore is not accessible via
| Core DOM navigation facilities such as firstChild or nextSibling.
| (See: DOM interfaces.)
>> Yet, there is no difference from a user perspective between our
>>theoretical binding and our theoretical implementation of the element.
>>If the binding altered the semantics, how is this possible? The answer
>>is simple: It isn't.
>
> The user has no knowledge of the binding in code. The user may also not
> view the markup. The important factor is that things that do view the
> markup, e.g. search engines, can know that the data items are countries.
Stuff involving search engines and other such user agents is better
handled by providing microformats anyways. If I add a special strip of
buttons to a "Search" text box that allow you to build a search string
more easily, why does the search engine need to know the inners of my
search box binding implementation? It just needs something like "search"
in the |class| attribute or something.
In theory, a binding could be on a semantically useless element (such
as a <span> or <author-pulls-an-element-name-out-of-his-arse>), but in
that situation, we'd only be looking at the binding because what it
binds to has no useful semantics in the first place. Using the current
search engine model, a search engine would ignore the CSS, find a lack
of semantics in the document, and ignore it or give the page a low
search score. In that manner, good semantics in the original document
and microformats are encouraged, while multiple implementations of
semantics via bindings can proliferate.
>>This is made more clear when you consider that the bindings may be
>>different based on the stylesheet selected. If you have alternate
>>stylesheets, which one contains the "semantics" you speak of? Does the
>>meaning of the document then change based on the stylesheet selected?
>
> Exactly! You have stated one of the problems with conflating style and
> semantics. Read for more:
>
> http://lists.w3.org/Archives/Public/www-style/2005Nov/0157.html
It's only a problem if you believe that the binding attaches
semantics to the elements it binds to. If you do not hold that belief,
the problem no longer exists. I would agree that there may be semantics
internal to the bindings themselves, but I do not feel those semantics
are necessarily transferred to the bound elements.
>> The Semantic Web is for the exchange of DATA, not implementation.
>
> Yes, for example the knowledge that the data types are countries.
How does a binding to a map UI tell us what a country is? Are we
supposed to find out what a country is by checking the imagemap
coordinates? Or the event scripting? Or the binding specific styling?
What part of the binding contains the semantics? The binding doesn't
define semantics, it defines an underlying implementation.
Reading the source code of a browser would not necessarily yield
element definitions identical to those in the HTML 4.01 spec. That
doesn't mean that the browser isn't compliant. It merely means that the
spec defines the semantics, while the browser is an IMPLEMENTATION of
the spec. Similarly, a binding doesn't contain semantics. At best, it
simply implements a compliant implementation for predefined semantics.
>>The purpose of XBL is not to give user agents additional information about
>>the markup, but to add author-defined features on top of those provided
>>by the user agent.
>
> I know. That is the problem.
There are two cases I can come up with where that might be a problem:
1) The web author designs a page that's inaccessible to user agents who
have support for XBL.
2) The web author designs a page that's inaccessible to user agents who
don't have support for XBL.
The first problem is really a non-issue. It can be defeated in
numerous ways, and it will inevitable decrease traffic from users of
XBL-enabled user agents.
The second is slightly more disturbing. The idea is that authors may
put actual content in XBL bindings rather than the page itself. While
disturbing, it has MANY drawbacks:
* It requires XBL to gain critical mass in the marketplace.
* It makes content inaccessible to current search engines and other
similar user agents.
* The entire page becomes useless when the CSS file or XBL file fails
to load.
* It makes your website unnecessarily difficult to manage.
* It increases the load times and memory requirements of your website.
* Individuals may boycott your site because of your exclusionary
practices, even if their user agents support your page.
* Mistakes in binding can lead to missing content.
So while I'd agree there is some potential for abuse, there really
isn't a lot of MOTIVE for abuse on the Internet. (Intranets may be a
different story, but in that situation the company may be using any
number of proprietary and exclusionary tactics already, so there's
nothing new.)
>>Searching the XBL binding does not yield any new
>>data, and in fact the binding can be changed, overridden and disabled.
>
> If the XBL interprets the contained information of the affected tag in a
> way that implies additional semantics, e.g. that the inputs are countries,
> then indeed this is new semantic information.
But it doesn't know what a country is. It only knows that when it
sees "country", it's supposed to display an image map and run some
script. If XBL could actually attach additional semantics to an element,
it would be an Abstract Concept Definition Language.
>>The Semantic Web can effectively ignore XBL, just as search engines can
>>ignore CSS.
>
> And thus ignore any semantic information the XBL script creates by it's
> assumptions about the anonymous content of the tag (e.g. that they are
> countries). In markup, we imply semantics via tag names and attributes
> (not anonymous).
The |id| and |class| attributes can tell us far more than any
fictional analysis of a binding's scripting, markup and styling done by
some futuristic AI. In fact, if I were an AI, I'd probably just match
the class name "country" against my internal dictionary.
>>Shelby Moore wrote:
>>>Thus via XSLT, we get the rich styling via subclassing, without the
>>>obscuring markup semantics.
>>
>>Huh? From what I can gather, "x:Class" is nothing more than a binding
>>to a class in a "code-behind" file. How is this any different from
>>binding the same code using XBL?
>
> Because the binding is correctly in markup, not incorrectly in CSS.
Except that I don't except that it is incorrect to bind via CSS, so
your answer is meaningless in that context. See the definition of binding:
http://www.mozilla.org/projects/xbl/xbl2.html#binding9
| A binding is the definition of behaviour that can be applied to an
| element so as to augment its presentation.
> Read:
>
> http://lists.w3.org/Archives/Public/www-style/2005Nov/0157.html
Why don't you just quote the relevant passage instead? I don't have
time to dig through another one of your multi-page meanderings to find
what I _think_ you're talking about.
>>HTML:
>>| <select class="SmartDataSelect">...</select>
>>
>>CSS:
>>| select.SmartDataSelect { bind: url(SmartDataSelect.xbl); }
>>
>> Actually, there's a big difference, but it's not obvious in the
>>example. With a selector system, we can apply the bindings over a broad
>>range of markup rather than a single element.
>
> Oh yes, selectors are really cool. I had stated that already in this
> thread. But they come with massive interoperability problems when used
> for semantic layer:
>
> http://lists.w3.org/Archives/Public/www-style/2005Nov/0157.html
I cannot clearly determine the nature of the "interoperability"
problem from this post.
>> As you can see, the whole idea of the bindings being "subclassing" is
>>false. In theory, a binding could be applied to an indefinite set of
>>elements, not just one.
>
> Whether it is one or many, they are still subclassed.
Calling an element a class doesn't make it so. XAML may map elements
to classes, but that is specific to XAML, which is not a semantic language.
>>>So how does CSS style arbitrary subclasses?
>>
>> If by that you mean "How does CSS style elements in the shadow
>>tree?", I believe that's defined in the XBL 2.0 spec:
>>
>> http://www.mozilla.org/projects/xbl/xbl2.html
>
> I mean once we stop conflating semantics and style, how do things that are
> style (not semantics) get applied to arbitrary class? For example, how
> does "color" apply to sound class? What CSS attributes apply to animal
> class? Etc. Think more broadly than GUI please. The Semantic Web is at
> least trillion times more broad than some GUI widgets.
You're not making sense. CSS applies to elements that match specific
selectors, not programming classes, and the properties are presentation
hints, not carved-in-stone rules. The user agent is perfectly free to
ignore a CSS property if there is a valid reason to do so. If you assign
a "color" property to a <sound> element, the UA can just discard it.
>>>[Do] CSS properties only apply to normative type and those that inherit
>>>from them?
>>
>> I'm not clear as to what you mean by that.
>
> Does "block" apply to bird class?
If by "bird class" you mean an element with the class name "bird",
why not? Are authors somehow restricted in their use of style based on
your personal opinion of how a specific "class" can be presented?
>>>How do we decide which properties are style and which are semantic?
>>
>> You don't. They're all style.
>
> I predicted the "Moz-tribe" would make this error!
Are you trying to be labeled a "troll", or are you genuinely unaware
that you're using a slur?
> http://lists.w3.org/Archives/Public/www-style/2005Nov/0157.html
>
> "I hear 'Moz-tribe' thinking 'all of them!', then we are back to obscurity
> of for example treating data as 'countries' when the <select...> knows
> nothing about data type it selects."
Can you even give an example of markup defining the semantics for
markup? XSLT is not such an example. Transformation take advantage of
the existing semantics of a target language, and often involves data loss.
Besides, the definition of "binding" for XBL doe not include passing
or inheritance of semantics. (See the previous citation.)
>>>That is what I am hoping to see in "Future of CSS in Semantic Web?"
>>>thread.
>>
>> What is it about presentation and presentation-specific UI and
>>behaviors that you think is necessary for the proper function of the
>>Semantic Web?
>
> For example, that when an XBL script interprets data as countries, that
> the Semantic Web will know also.
The biggest advantage of XBL is that it allows advanced styling of
dynamically generated elements. If an element is dynamically generated,
it only exists on the client unless submitted to a server, so the Web in
general won't see it. Therefore, for the primary XBL use case, we're
really talking about "The Semantic Client".
If we were to have an element that is completely static and has no
dynamic counterparts, you could just use XSLT to transform it, sure.
That's a perfectly valid use case. I'm not anti-XSLT; I simply don't see
XSLT as _excluding_ XBL.
I am, however, against using client-side XSLT. It's just as easy to
do the transform on the server, and you can control the hardware and
software that performs the transform to improve reliability. Output can
also be cached on the server. Plus you don't have to depend on the likes
of Microsoft to implement the newest version of XSLT. (Remember that
XSLT 2.0 is in CR, whereas I believe Microsoft only supports 1.0) Also,
there are still browsers that don't support XSLT, as it is an optional
technology for HTML user agents.
Received on Monday, 28 November 2005 15:05:47 UTC