Re: ISSUE-41/ACTION-97 decentralized-extensibility

2009/10/19 Krzysztof Maczyński <1981km@gmail.com>:
> Your differentiation based on this between scripts and browser extensions doesn't seem valid to me. Both could use @class (and some indeed do with current HTML, often unfortunately) or elements in another namespace. So your point would have to be taken equally against arbitrary @class as arbitrarily namespaced elements.

It's true that nonstandard extensions could use things like class,
data-*, and so on.  This is unpreventable.  But it doesn't mean we
need to add further mechanisms specifically to accommodate these
extensions.

On Mon, Oct 19, 2009 at 7:45 AM, Shelley Powers <shelley.just@gmail.com> wrote:
> The use of class names is moot, because they don't provide a process
> whereby we can ensure that there are no name clashes with class names.

Classes are reserved for use by scripts and styles provided by the
page author, who will be able to prevent conflicts directly by
modifying the scripts/styles if necessary.  Therefore, name clashes
are not a serious issue.  They're an annoyance at worst.

On Mon, Oct 19, 2009 at 7:59 AM, Shelley Powers <shelley.just@gmail.com> wrote:
> I'm not sure where the concept of proprietary tools enters this. I
> have seen HTML used for proprietary tools, and CSS, too -- should we
> then desist in working on these? Or should we accept, as fact, that
> any open specification can be, and will be used, in proprietary tools.

The problem is not that the tools themselves are proprietary, but that
data is exchanged in formats that only proprietary tools can read.
That's what the W3C is supposed to be working against, as a standards
body.  One of the major goals of HTML5 is to replace technologies like
Flash with standardized solutions, for example.  HTML5 is in most
places very careful to prohibit extensions by user agents.  (The only
exceptions I can think of are <object> and <embed>.)

> That's a risky path to walk. You've just equated proprietary with
> standard, and then stated non-standard should be invalid. Are you
> saying that all proprietary uses of HTML5, then, should be invalid?

No.  I'm saying that any document that cannot be fully processed by
any party based solely on published, royalty-free standards should not
be valid.  Documents that contain significant content in a nonstandard
format should be invalid HTML.  The prevalence of such documents is
contrary to the goals of the W3C and an open web.  As I understand it,
that's why HTML5 specifically prohibits any extensions by user agents
that are not appropriately standardized.

On Mon, Oct 19, 2009 at 9:03 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> 'Unstandard data formats' and 'undesired features' are different concepts.
> Decentralized extensions = standard format.

By that logic, isn't anything written in XML standardized, because XML
is a standard data format?  A language that has standardized syntax
but unstandardized semantics is subject to all the problems I
mentioned.

> Class names are however often something that you add /after/ you have done
> the mark-up.

It depends what you're using them for.  For instance, if you're using
JavaScript to provide essential functionality, then you'll add the
class from the beginning -- else it wouldn't work at all.

> I could not disagree more. You could simply try to create striped tables
> rows effect ... Those UAs which support :first-child and the adjacent
> sibling combinator (E+E) lets you do that fairly simple (of course, could be
> made simpler ...), without adding any class or anything. Whereas e.g. IE6
> requires that you add a "to be striped" class to every second TR element.

Good point -- what I said wasn't quite accurate.  It would be more
correct to say that classes for CSS are a pain to rely on because CSS
is a relatively simple declarative language, so you have to add
classes all over the place if selectors happen not to support your
exact use case.  This is moot for a Turing-complete solution, such as
JavaScript.  If you wanted to modify every second row using
JavaScript, you could iterate through all the rows and do whatever you
want just using features of JavaScript.

In any event, it would be no more convenient to have to write
<oddrow:tr> or such than <tr class="odd">.  I don't see why namespaces
are at all different to classes here.

> But even if a prefixed solution would require more typing, you would get the
> strucrre "for free". Adding classes, however, requires that the author
> analyze and understands his own code. Only then can he add the classes
> correctly. But even then, he must not make any human errors (think about the
> striped table) ... Whereas namespaces based selectors /helps/ the author
> understand the code he has written.

I'm afraid I don't see what you're saying here.  There is no logical
or functional difference between <foo:span> and <span class=foo> from
the point of view of any commonly used standard web technology (CSS,
JS) I can think of.  Given a page with a bunch of namespaces, and some
scripts or styles that do something with the namespaces, it would be
pretty trivial to rewrite everything to use classes instead,
indistinguishably.  The differences would seem to be things like
avoiding name conflicts, the amount of typing required, copy-paste
resilience, etc., not how they can actually be used.

> Agreed. But how HTML 5 should look like is what we are discussing.

Yes.  That part I covered in the rest of my post.

> By having a standard, decentralized method for extensions, we make sure that
> extensions do not develop as "facts on the ground" that subsequent version
> of HTML would need to take into consideration *regardless* (under the motto
> "don't break the Web").

I don't see how this is so.  If Flash had used <flash:video> instead
of <object>, would that have made it any less a "fact on the ground"?
The goal should be to discourage all nonstandard extensions as
strongly as possible.  It's not possible to stop them entirely, no
doubt, and that probably wouldn't even be desirable.  But they can at
least be made invalid -- that's about all the influence the HTML
Working Group has here.

Received on Monday, 19 October 2009 16:26:32 UTC