I agree with Sam. In particular:
1) Calling a participant "shrill" invokes gender stereotypes in a way
that is completely inappropriate.
2) Your recent emails on distributed extensibility are useful
technical input and are welcome on the HTML WG mailing list, as far as
I'm concerned.
3) I think you and Henri should continue your discussion on the list
as long as both of you can keep it level-headed and about the issues.
So far, I believe both of you have.
Regards,
Maciej
On Oct 2, 2009, at 1:06 PM, Sam Ruby wrote:
Shelley Powers wrote:
I'd reply to your comments, Henri, but evidently my emails are not
welcome, and are considered, now what were the words? Oh yes,
"shrillness" and "hyperbole".
While I condemn such statements, I haven't seen them from Henri.
And while your statement may or may not be welcome on WHATWG mailing
lists and IRC channels, let me assure you that your emails are
welcome on W3C provided venues.
Interesting how "shrill" is used when women communicate in tech
discussions. About as interesting as statements about it being more
cost effective just to hire someone from a third world country to
read to the blind, rather than implement accessibility for the web.
"Interesting" is a polite word for it. I can think of a number of
other words.
Shelley
Henri Sivonen wrote:
On Oct 2, 2009, at 19:41, Shelley Powers wrote:
Henri Sivonen wrote:
It seems to me this needs to be assessed in the context of use
cases. It would help to know what kind of state editor vendors
would like to save, what mechanisms they use now and what
state saving they recall they have foregone due to lack of
syntax in HTML.
A use case was provided. I added to it. If you don't find it
sufficient, feel free to reject.
A general class of use cases was provided but no concrete cases
that'd allow solutions to be evaluated.
What do you mean by "concrete"?
A specific example of what kind of state an HTML editor tool wants
to save.
No, I didn't say that RDFa is a decentralized extensibility, by
itself.
OK. For clarity, are you saying that RDFa *isn't* "a decentralized
extensibility"?
And that is a good form of openness, though as you say, not
without its own challenges. But, that's more of a application
extensibility rather than a markup extensibility. Yes, HTML has
object, but that's so browsers could be extended with
additional functionality.
This proposal is talking about extensibility at the core level,
in the markup, itself.
Frankly, two different things.
[...]
I'm sorry, but I don't understand what you're saying here.
Could you rephrase it?
How is an ActiveX control that hooks to <object> and a byte
stream different *from the user point of view* than an ActiveX
control that hooks into "custom tags" in IE? In both cases,
there's content out there that you can't read in your browser
without installing an additional piece of software, and the
piece of software isn't available for all browsers on all
platforms.
Henri, sorry, I'm probably being particularly dense today, but
I'm not sure how this is related to the Microsoft proposal.
IE today allows ActiveX controls implement rendering of "custom
tag" subtrees. I'm interested in understanding the relationship of
that feature to the proposal.
How does the Web become better if additional pieces of native-
code software hook to the DOM in addition to hooking to <object>/
<embed> and a byte stream?
Native code software?
Code implemented as instructions native to the CPU. The way NPAPI
plug-ins and ActiveX controls are implemented.
Well, when it comes to namespaced elements in SVG in an HTML
document, I can see immediate benefit to JS libraries accessing
those elements.
SVG is not a "decentralized" extension to HTML, AFAICT. It's
centralized right here at the W3C together with HTML.
So, let's ignore the implementation details and focus on your
concerns about decentralized extensibility. Is your concern,
then, that no one has provided an argument you can agree with
that decentralized extensibility is needed? You did question
Tony's proposal, but I didn't see you question the assertions in
the proposal about the need for extensibility, only specific use
cases. What exactly do you have against decentralized
extensibility? If you can list out the specifics, perhaps we
could discuss them, one by one.
I can't agree or disagree on whether 'decentralized extensibility'
is needed and I can't say what I have (if anything) against it
without knowing what 'decentralized extensibility' is. It would be
helpful to have a necessary and sufficient definition of what
language characteristics constitute 'decentralized extensibility'.
Is the set of characteristics a proper subset of the
characteristics of Namespaces in XML or are the sets one and the
same?
* When content depends on language extensions that need client
software extensions to process, the ability of users to read Web
content is harmed in software/hardware environments for which
the client software extensions aren't available.
I would say that a significant proportion of HTML5 falls into the
category of needing implementation that isn't universally
available in all environments.
As far as I know, the HTML5 spec is royalty-free and it's being
implemented in multiple engines some of which are Open Source.
There doesn't seem to be any one party controlling the
availability of an HTML5 implementation for a given computing
platform.
* Working with string tuple identifiers is harder than working
with simple string identifiers.
Again, this has nothing to do with your concern about
decentralized extensibility. I think we should focus on the most
significant concern, address it, and then move on to
implementation once past that initial concern. Don't you think?
It depends on whether 'decentralized extensibility' is synonymous
with Namespaces.
* Prefix-based indirection (where the prefix expands to
something as opposed to being just a naming convention) confuses
people.
Again, outside of the initial concern about decentralized
extensibility as a whole.
It depends on whether 'decentralized extensibility' is synonymous
with Namespaces.
