- From: Shelby Moore <shelby@coolpage.com>
- Date: Fri, 25 Nov 2005 20:48:55 -0500 (EST)
- To: www-style@w3.org
Apologies I didn't see this reply, we posted at almost same time, else I would have included my rebuttal in my previous post today... Boris Zbarsky wrote: > Shelby Moore wrote: >>> <map name="foo"> >> And I don't think the semantics are obscured, if transforming from >> unspecialized <select> to <map> you have above. > > <map> is HTML markup for an imagemap, no relationship to geographical > maps. The semantics went from "way to select a country" to > "image with some clickable regions", with no indication that > the regions correspond to countries. Irrelevant, but correction, the semantics went from "way to select any type of data" (not country type of data). It was your example, not mine. I have given a more useful example: http://lists.w3.org/Archives/Public/www-style/2005Nov/0155.html >> I assume the style (XSLT) coder didn't want to imply "country" >> semantics, only "map" semantics. > > The point is, the XSLT coder COULD NOT imply "country" semantics and work > reasonably while dealing with HTML markup. Incorrect. See my example in above link. >> Whereas, XBL (binding scripting at style layer) enables the consumer, >> UA, coder, etc to obscure semantics architecturally. > > XBL bindings never change semantics -- the semantics are always right > there in the markup. I don't know whether you're just ignoring this or > whether you missed it. XBL bindings do have the capability of changing semantics. For example, if we have an unspecialized <select> in semantic markup with unspecialized contained children (<option>), and then bound SmartDataSelect.xml XBL code then interprets the children as countries, then the XBL has indeed subclassed the semantics from "any data" to "country data". To go one step further, in the post at above link, Mark and I have shown that the contained children could be specialized semantically in markup. And I have still argued that the XBL code could implement more features in subclassed semantics that are not implied by the specialized children. No matter how you slice it with an example, there is the _potential_ for scripting code to subclass semantics. But as for parsing the binding... As I explained in my post at the link I gave above, yes the binding to subclassed semantics is in the style markup layer when CSS is used to bind XBL code. We could parse that to get the semantic subclass. But we don't want the _OUTPUT_ of semantic markup subclassing in the style layer markup. In CSS markup, there is no markup transformation, so the _OUTPUT_ markup is still in the CSS style layer. Whereas, with XSLT, the output is in the semantic markup layer. And why don't we want semantic markup in the style layer? See the linked post above please. I can not think of more ways to say the same thing at this time. -- Kind Regards, Shelby Moore http://coolpage.com
Received on Saturday, 26 November 2005 01:57:56 UTC