W3C home > Mailing lists > Public > public-html@w3.org > August 2008

RE: Extensibility strategies, was: Deciding in public (Was: SVGWG SVG-in-HTML proposal)

From: Justin James <j_james@mindspring.com>
Date: Wed, 6 Aug 2008 01:01:37 -0400
To: "'Julian Reschke'" <julian.reschke@gmx.de>
Cc: "'Ian Hickson'" <ian@hixie.ch>, "'HTML WG'" <public-html@w3.org>
Message-ID: <079101c8f781$8181fa00$8485ee00$@com>

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Tuesday, August 05, 2008 10:33 AM
> To: Justin James
> Cc: 'Ian Hickson'; 'HTML WG'
> Subject: Re: Extensibility strategies, was: Deciding in public (Was:
> SVGWG SVG-in-HTML proposal)
> Justin James wrote:
> > ...
> > If the URI/URN (or whatever UR*) class names are not being de-
> referenced,
> > then who *cares* if there could be a clash somewhere? It is
> irrelevant, so
> > long as the CSS tree for the current document does not have any
> clashes. And
> > if it were, who cares? Because CSS handles multiple definitions just
> fine,
> > the one "closer" to the tag (externally defined, then internally
> defined,
> > then inline style) overrides indentical attributes while allowing
> > non-identical attributes to inherit up.
> >
> > So I really am not sure why you guys are so worried about clashing
> class
> > names, it seems like a non-problem to me. Am I missing something?
> > ...
> I was responding to the proposal of using class names as extension
> points, putting semantics into the document (as a workaround for HTML's
> missing extensibility).
> In that case, the class name itself provides information (and its use
> in
> CSS is irrelevant). So a potential collision of names would confuse the
> recipient, who's expected to extract information out of the presence of
> the class name.

Gotcha, this is a usability-based objection, not a technical-based one. It's
a good point.

> >> - the spec to give rules for the formats of these names, so clashes
> are
> >> avoided (if you use a URI, use one you have authority over), and
> >
> > This concept of mandating that the HTML author have "authority" over
> a
> > URI/URN that they are using as a class name is not working for me.
> This is
> > the second time that you've mentioned it, but I really do not
> understand:
> >
> > * How do you want to define "having authority over"?
> For resolvable URIs: the ability to put content there. For
> non-resolvable URIs it's harder to define and depends on the scheme.

At the domain level? In general? For example, if I have a geocities account
(do they even exist still?), where does my "authority" end and start? In
general, I know the answer that you have in mind, and I am not trying to
bust your chops here by pretending to be dumb, I'm just trying to show that
it is very difficult to put this kind of language in a spec since it is so
hard to define what you mean. "I know it when I see it" really doesn't make
a spec that works.

> > * How do you handle someone importing a CSS stylesheet from a URI
> that they
> > do *not* "have authority over*, such as is the case when using a
> public
> > widget library?
> How is that a problem?

I might be confused here, so I'll give you an example of what I am thinking

A page at abc.com has a link to a stylesheet at xyz.net. Let's say that the
stylesheet at xyz.net contains the follow class definitions:

* http://www.xyz.net/datetime
* http://www.abc.com/price
* http://www.yahoo.com/classes/WidgetLibraryContainer //For use in wrapping
around a Yahoo! widget

So where are the violations of this principle? Is the stylesheet allowed to
contain classes for "abc.com" only when it is used in HTML at abc.com? Is it
an error for a document at abc.com to use one of the xyz.net classes? Are
both the document and the stylesheet wrong by using the reference to

Like a lot of my questions, BTW, this is meant to get clarity. I don't think
that I have a really clear understanding of what we are talking about (I
suspect we may be talking past each other).

Thanks for your patience!

Received on Wednesday, 6 August 2008 05:02:45 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:36 UTC