[whatwg] some issues

Jim Ley wrote:
> What?  This is talking about general XML and why sniffing isn't
> appropriate, it doesn't talk about applications of XML such as XHTML
> which are free to put whatever further constaints it feels like, and
> as has been quoted XHTML requires a doctype.

    /me shrugs.

    You're on your own Ian.

    /me walks out of the room and closes the door.

>>   On the contrary, a monolithic proposal would be a disaster. It
>>creates an "eggs in one basket" scenario where the W3C could reject the
>>entire specification.
> 
> I'm not sure I understand the relevance of the W3 here, the WHAT WG
> members have refused to say which standards organisation they're
> taking it to (and as they're not members there's nothing stopping them
> from.)

    W3C = a standards organization. Sort of a Freudian slip.

>>   WHAT WG has wisely elected to take a modular approach to these
>>drafts.
> 
> It's not really modular is it, only spec is in even a remotely
> meaningful state, if you're right and there's no independence between
> them (which isn't a sentiment I've seen from elsewhere on the list)
> then they're not modules.

    Huh? Your high school English teacher would have you shot for that!

    Looking at the modules in the "Modularization of XHTML" 
specification, it would seem that XHTML modules can cover as little as a 
single element or attribute. However, they can also cover entire 
categories of elements, like the Forms Module:

http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_extformsmodule

    So, Web Forms 2.0 could be considered an XHTML module based on the 
Forms Module, while Web Apps 1.0 could be its own brand new XHTML 
module. Web Controls 1.0, however, doesn't seem to fit this at all.

 > If they are modules with interdependence,
> then they need to be at similar levels of maturity, in that case, I
> agree they might aswell be in a single spec.

I don't really see how they would be _XHTML_ modules with 
interdependencies. The only thing that might belong in a forms-related 
module is the RTF control, and even then you could just specify that as 
having its own module and making Web Apps 1.0 a multi-module spec 
(assuming grouping it with other widgets like tabs would offend your 
sensibilities). Web Controls is pretty much the domain of CSS, DOM and 
XBL, so I don't see the need to group it with the other specifications.

>>1) The time it takes to get feedback from a standards organization is
>>significantly reduced.
> 
> There's no feedback from standards orgs being solicited in any of the
> specs at this time.

    What's your point? We can't get feedback on what we don't submit, 
therefore the longer it takes to write a spec, the longer it takes 
before we get feedback. Clearly it will take longer to write one 
monolithic draft than it will to write a smaller, more focused one.

>>3) Problems encountered during the submission of earlier drafts can be
>>addresses in later drafts.
> 
> Sorry, I don't really see how this is a strength of split ones, or do
> you envisage the Web Controls 1.0 spec fixing the problems of Web
> Forms 2.0?

    More along the lines of if W3--er--the various standards 
organizations seem resistant to specific concepts or wording, we can try 
something different in the next spec, or try submitting to a different 
standards organization.

>>This is less likely with a monolithic spec,
>>because the more general topic may not attract their attention.
> 
> I've never seen this to be a problem with other specifications,

    If you're interested in CSS3, do you read all the various drafts or 
just the ones that interest you?

> I
> think the bigger problem with the WF2 spec is the lack of commentary
> from the "likely suspects".  The current commentary is from a very few
> developers, there's even only 3 or 4 of the Working Group themselves
> ever commenting on suggestions.  If we can't even get their expertise
> into the spec, how can we expect 3rd part people?

    You're assuming that they have comments and that when they do, they 
express them in the mailing list. This is not necessarily the case. 
Besides, what are you going to do, make Ian make his fellow members post 
their comments on the mailing list?

    Furthermore, standards organizations have plenty of experts of their 
own. If we miss something, they can fill in the gaps. The proposals we 
produce don't have to be perfect.

>>   I seriously doubt that the W3C will throw out the entire Web Forms
>>2.0 proposal over a disagreement over DOCTYPE.
> 
> So you agree the W3C is the only option to take this to a standards
> body?

    /me rolls his eyes.

    See above comments on Freudian Slips.

>>   So do we tell everyone with web-enabled phones "tough luck"?
> 
> Currently the spec only claims to extend HTML 4.01 and XHTML 1.1, it
> makes no mention of XHTML Basic at all.  So that looks like what's
> happening...

    First of all, the N-Gage uses something called XHTML Mobile Profile 
(XHTML MP). Maybe you know something I don't know, but I'm not sure this 
is the same thing. Secondly, why can't we just create a Web Forms 2.0 
Mobile Profile?

>>If
>>the developer isn't worried about implementing each of the three
>>specifications one at a time, I'm not going to worry about it either.
> 
> The problem comes when you're deciding how to implement things, I
> believe C Williams comments were suggesting that a vendor other than
> Opera/Safari/Mozilla could feel at a disadvantage because they don't
> know what's coming up in the next module of the specification that may
> heavily impact on how to design something.

    Why would they not know that? Their browser isn't compatible with 
the archive site? They have trouble with our mailing list? An open 
process means not being surprised by the final draft. Heck, a developer 
even has the option of asking us not to implement a feature in a 
specific way if it's difficult to fit into her/his browser architecture.

    So where's the disadvantage? Are you suggesting a conspiracy between 
WHAT WG members to keep early versions of the spec out of the public eye 
  to give Opera, Mozilla and Safari a head start? Not likely, especially 
when you consider the fact that the guy running the show is the same guy 
leaking early drafts of the XBL2 proposal.

> For example if Web Controls says that authors can style input
> type=datetime into 3 select boxes by some mechanism, then the WF2
> implementation would need to be flexible enough to deal with this.  

    Only if you want to support Web Controls 1.0.

> There are many excellent browsers in competition with Opera on the
> mobile platform, I was rather intentionally anti-opera in many
> previous comments on this list, not that I necressarily believe those
> situations, but as C Williams says, the need to be seen to be
> independant, and above reproach is so important.

    Perhaps rather than using scare tactics ("WHAT WG is an Opera 
puppet!") to make this process more open and impartial, you should just 
outright suggest how the process could be more open and impartial.

>>   With all of the top browser developers except for Microsoft being
>>represented in WHAT WG
> 
> I'm sorry, I don't agree with this, both Macromedia  and Adobe are not
> represented, neither   are the many mobile  browser  vendors,  some of
> who'm almost certainly have more UA's shipped than Safari.

    Here's why I don't care:

1) I see no attempt on the behalf of WHAT WG to prevent these vendors 
from participating. In fact, I see no reason to believe that employees 
of these vendors couldn't become WHAT WG members if they so desired. 
(That reminds me, who does Dean Edwards work for?)

2) By the time Longhorn comes out, most of those mobile phones carrying 
all those UAs you seem to care so much about will be sitting in a 
landfill. On the other hand, if the desktop market moves to WHAT WG 
standards, the phone UA vendors will follow suit(sp?).

3) Macromedia and Adobe have no interest supporting Web Forms because 
they both have competing products (Flash and SVG).

Received on Monday, 5 July 2004 17:57:18 UTC