On Feb 19, 5:46 pm, Ian Hickson <i...@hixie.ch> wrote:

This is not a good argument, we're looking for an order of magnitude
more adoption. That is sub-silverlight success.

How did they override you? You're the dictator. At any rate, but that
absence doesn't mean SQL needs to go in the HTML spec. It could be
great, give it its own document, maybe it will take off. Does that
make sense?

I am responsive to the argument that you're one the doing the work, so
I took steps to produce the approach I believe in.

- Rob

Sure. It's still early days.

No, I'm the editor. There are many things in HTML5 that I don't think are
good ideas, like the allowance for XML-like /> syntax, the SQL database
feature, element.innerHTML for XML nodes, document.write(), quirks mode,
etc. However, I'm not writing the spec to match my personal desires, I'm
writing it based on use cases, logical arguments, research, and reality.

Yes; the entire local storage section is already planned for extraction.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

On Feb 19, 7:25 pm, Ian Hickson <i...@hixie.ch> wrote:

You're the dictator. Am I reading the WHATWG process wrong?

That's not a good explanation for adding to the scope of the document.

If they shouldn't be there, why did you add them? I confess I don't
actually care what the answer is, and I'm more interested in removing
the ability of anyone to unilaterally add to HTML. Nothing
personal. :)

- Rob

Apparently. A dictator, by definition, has total power. I have nearly no
power; I am contrained by legacy content, by the whims of implementators,
by rational and logical argument, by the needs of authors and users, and
by research.

It wasn't an explanation for adding to the scope of the document. I was
explaining that the spec doesn't represent my opinion.

I don't really think that the local storage section shouldn't be there; it
is being extracted because people like you think it shouldn't be there.
Personally I'm quite happy with a monolithic spec and would be quite happy
to absorb more specs into it, as I think it leads to higher quality spec
material. However, that's not the direction we're going in.

I have no ability to add anything to HTML. Only implementors do.

I don't even have unilateral power to add anything to the HTML5
specification I edit; the WHATWG members have veto power in the WHATWG,
and the W3C working group and W3C staff have veto power in the W3C.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

On Feb 19, 7:57 pm, Ian Hickson <i...@hixie.ch> wrote:

Incorrect by most definitions, including all of the practical ones.

I don't think you'd find me participating in the W3C if I was happy
with the WHATWG or its board.

You can claim SQL "is planned for extraction" all you want, but that
doesn't change the fact Google is out there marketing "HTML5 Storage
For The iPhone". Given the shoddy rationale for inclusion,
collaboration on WebKit, the fact that your CEO sits on Apple's board,
and the editing model of HTML5, that looks horrible! It doesn't matter
how well-meaning the effort was, and it threatens to compromise the
entire document. I don't have a problem with a JavaScript SQL API, and
I don't want to stop it. It's the "HTML5" part that I'm not going to
put up with.

- Rob

Wikipedia, the New Oxford American Dictionary, and answers.com, my three
main sources of definitions, all seem to agree that the term "dictator"
refers to someone who is an absolute ruler.

I don't particularly like semantic quibbling like this, but since this
sounds to me like a personal insult and attack on my work ethic, I do
somewhat take offense here.

 o_O

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

On Feb 19, 9:36 pm, Ian Hickson <i...@hixie.ch> wrote:

To use one example, the Wikipedia article reflects my opinion. The
term has more nuance than you implied, in my opinion.

<http://en.wikipedia.org/wiki/Dictator>

But beyond that, I should note that I didn't choose the term dictator.
In my conversations with WHATWG board members, that term has been used
freely. It also seems to be used by heavy WHATWG contributors

<http://krijnhoetmer.nl/irc-logs/whatwg/20090202#l-363>

It was not intended as insult or attack. I apologize for anything that
sounded so. Many communities refer to their "editor" as a "dictator".
Guido van Rossum is one example.

I know that message was impolitic. Let me reiterate that it's the
appearance I am concerned about, above all. The motivations of all
parties to the WHATWG seem good.

- Rob

In article <94GdnWY2L77x9QDUnZ2dnUVZ_heWn...@mozilla.org>,
 Boris Zbarsky <bzbar...@mit.edu> wrote:

My point is that the parts of CSS3 that were also in CSS2--perhaps also
in CSS1--and have been interoperable implemented are for all practical
purposes as stable as any Web feature gets even if the CSS3 spec
expression of the features have been marked as Working Draft.

My concern is this:

From outside the CSS WG, it seems like maintaining a CSS 2.1 spec
expression and a CSS3 spec expression of a given feature, has added
editorial overhead that slows the group down.

I see value in seeing to it that the features contained in CSS 2.1 get
interoperable implementations and have test cases. However, doing this
by maintaining a second spec in addition to CVS HEAD of the CSS3 drafts
seems to have a non-trivial cost due to the split of editorial effort
when the time of competent editors is in short supply.

My guess is that the cost would be less if there were only one spec for
each CSS feature with per-feature annotations of the level of maturity.
That is, I think tracking stability/maturity on the level of documents
instead of on the level of features is too coarse-grained.

The WHATWG copy of HTML5 tracks per-feature maturity and so far it seems
that this method of tracking has a much lower overhead than splitting
every piece that one wants to track separately into a separate spec that
needs to go through chartering, etc.

(Note that I don't think some pure JS API features intuitively belong in
HTML5, but since we don't see editors lining up for these features, I'm
willing to hold my nose if this is the way that at least keeps proposed
platform features specced and the realistic alternative is them falling
into the shady realm of unspecced features--in competing products no
less.)

I fear that splitting a separately maintained CSS 2.1-like "HTML 4.1"
out of HTML5 would lead to a split of effort that would be destructive
to the rate of progress.

However, maintaining only the tip of the spec by human work and
generating snapshot releases for the authoring public at large by using
the per-section annotations mechanically would probably not pose such
danger of split effort.

Furthermore, given the political considerations aired in the "Moving
past last call for HTML5" branch of this thread, I think it would be
premature to debate the proposed alternative take on HTML5 purely on its
technical merit before understanding its political goals.

Don't the annotations in the WHATWG copy of HTML5 and asking on IRC when
in doubt address communication with UA developers sufficiently?

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

In article
<294811be-d2ef-4b6c-b895-38b6e8542...@v42g2000yqj.googlegroups.com>,

Do I interpret you correctly when I interpret that to mean that you'd
like the W3C HTML WG put your cut-down draft on the REC track?

Do *you* intend what would be put on the REC track always be a
mechanically-generated subset of the WHATWG instance of HTML 5, or would
entertain the option of additive authorship?

Do *you* want to use it to send signals to implementors and/or Web
authors and/or someone else? What signals?

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

In article
<6d2ae224-695c-493d-9c14-d76bc5666...@41g2000yqf.googlegroups.com>,

That sentence implies you don't like W3C, either. What kind of structure
for ensuring platform coherence would you like for the open Web
platform? Do you agree that having multiple vendors supply
implementations of the platform while keeping the platform coherent is a
desirable aim?

Two browser vendors want to address use case X. Do you agree that it is
Good for the Web if they address it in a uniform way such that Web
authors don't need to do different thing for different browsers when
they want use case X addressed?

If yes, do you agree that it is Good for the Web if they circulate their
design ahead of time so that other vendors who aren't planning on
addressing use case X at this time and other interested parties may
point out design bugs for mutual benefit but aren't able to block the
first-movers from addressing use case X in *some* way?

If still yes, is the problem with SQL storage that competitors are using
the brand of "HTML5" to market a feature that you don't approve of?

If this is the problem, do you see this as mirroring in any way
Mozilla's use of "HTML5" in marketing the upcoming video features of
Firefox 3.1 when seen from the point of view of Microsoft, Apple or
Nokia? Microsoft hasn't appeared too enthusiastic about <video> at all,
and Apple and Nokia have expressed disapproval of the video codec that
Mozilla chose to promote under the HTML5 brand.

How, in your opinion, should Apple and Google have proceeded on the
topic of complex client side storage?

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

In article
<4042e89a-4802-4170-8dbb-660d66bf3...@j39g2000yqn.googlegroups.com>,

These are annotated, though.

I know it's hard, which is why a have tried to avoid criticizing the way
Hixie does things too much when I haven't been able to show a realistic
better alternative.

Most likely not regardless of how you define consensus.

The lack of two interoperable implementations per feature when moving to
the later stages of the W3C spec maturity is a much more concrete razor
for cutting a feature (later than at first Last Call). (I think two
interoperable implementations of the whole spec is not a useful razor in
any timeframe that the W3C seems to be pursuing.)

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

On Feb 20, 3:43 am, Henri Sivonen <hsivo...@iki.fi> wrote:

My opinion isn't important. I'm going to stay quiet.

In lieu of continuing to cross-post, those that wish to follow this
particular thread can do so here:

http://lists.w3.org/Archives/Public/www-archive/2009Feb/thread.html#m...

- Sam Ruby

Sure.  And in fact they're already covered by existing CRs or RECs.

I'm not convinced that this is what slows the group down, honestly.

Perhaps, though the hard parts come with feature interactions, not
features....

While probably true, tracking on the level of features is too
fine-grained unless the features are very orthogonal.

It does?  That's the first I've heard of it...  Which means it's not
obvious from looking at the spec.

That's true if we task existing editors with the work; not clear about
the situation when someone has volunteered to do it.

I'm not sure I follow.  There are no political goals I see in Robert's
proposal, other than the goal of focusing on things that are closer to
being stable and interoperably implemented or that are needed for
interoperability on existing content.

Not that I've seen.  Asking on IRC is actually about as bad as it gets
if you're working in implementing something: it completely interrupts
your train of thought, requires a synchronous response at possibly
inconvenient times, needs a net connection, etc.

I've never seen any of the annotations you mention, so I can't say that
they address the issue either.  I've certainly seen notes to the effect
that something is unstable, but there are plenty of things without such
notes that don't seem very stable to me either.

-Boris

Depends on which CSS3 spec. CSS2.1 + errata is always up-to-date and
accurate for the things it defines. For the things it doesn't define,
reading the CSS3 draft may or may not be helpful depending on how
mature and how outdated it is. There's a lot of stuff in CSS3 drafts
that will eventually get either thrown out or rewritten.

~fantasai

Right. And that's why those features are expressed as CR via the CSS2.1
spec.

Given the current level of stability for CSS2.1, I've found the cost of
keeping a CSS2.1 and CSS3 draft of the same feature in sync to be trivial.

The one area where this would not be the case would be the box model,
i.e. chapters 8-10 in CSS2.1. That section is extremely complex, has been
pretty much rewritten for CSS3, gets tons of issues, and hasn't been sync'd
up in years. But you can't really do per-feature annotations for the box
model anyway, because "features" in the box model description are hard to
separate out. (You'd have to mark stability by sentence, which would just
be absurd.)

As for splitting things into independent modules and levels, I'm very,
very glad we did it. Working with a monolithic spec might be efficient
for hixie, but I just cannot wrap my head around something like that.
I edit multiple specs, and I'm glad that they're not one file, and get
published independently, etc. There are many things that slow me down,
but editorial overhead from splitting specs isn't one of them. It makes
it easier to publish drafts, easier to gather feedback, easier to track
progress, and easier to lock down CSS3, stable subset by stable subset.

I'm not going to argue about the best way for the HTMLWG/WHATWG to work,
but I think the CSSWG has a system that works well enough for it. Our
primary struggle is locking down 2.1, and the discussions surrounding its
issues are the primary time sink for me.

~fantasai

Little boxes in the left margin. They also show which of the major
browsers support the features, and have boxes for links to test cases and
demos, though those are rarely used right now. Anyone can edit the boxes,
alt-double-click on them to bring up the editor.

I welcome suggestions for making them more obvious. Not sure how to do it.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

On 20.2.09 00:25, Henri Sivonen wrote:

This is what most worries me about the current process (which, in most other respects, I find works well and has produced quite good results).

Just because one vendor implements something doesn't mean it automatically deserves to be specified, nor does it mean that a halfway proposal, once implemented by one vendor, need not carry its own weight in progressing toward well-definedness to remain in the HTML5 draft.  For an example of the latter, consider the current database functionality: the complete absence of a definition of the syntax of the SQL string to be executed makes it a total non-starter as part of HTML5 at this point in my book.

I don't think it's right to keep something in HTML5 just because it's useful functionality that nobody else is willing to drive to completion.  That produces a moral hazard of competent editors not stepping forward because it's less effort to keep such features in "holding patterns" than to actually do the legwork to make them implementable.  Continuing the database example, without a SQL-subset syntax definition, or without at least a strong start on it, I don't think databasing as currently in HTML5 is implementable in a way that's even facially vendor-neutral.

If no one else is willing to edit a feature that requires little effort to extract from HTML5 and that doesn't have complex interactions with fundamental HTML5 processes or (potentially new but fundamental) concepts (parsing most obviously, callback lifetimes as one more example), it doesn't deserve the false accreditation currently being in HTML5 (or even temporarily being standardized there) gives it.

Jeff

On 2/21/09 12:30 AM, Ian Hickson wrote:

Just as an example, saying that some feature is "Marked for extraction"
doesn't say much about its maturity.

-Olli

Good point. Fixed. Thanks.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

In article <499F5894.6020...@mit.edu>,
 Jeff Walden <jwalden+...@mit.edu> wrote:

I disagree. I think it's important for all additions to the platform to
have a spec that is precise enough and patent/copyright-wise free enough
to allow the next vendor who whatever reason wants to address the same
use case implement the same solution interoperably by reading from the
spec and without resorting to extensive reverse engineering of the
first-mover implementation.

It doesn't follow, though, that any organization in the business of
issuing de jure endorsements of features needs to endorse such a spec,
and it doesn't follow that the spec needs to be rolled into "HTML 5".

I see this as a point in favor for having things specced from early on
rather as a point showing that speccing single-vendor additions isn't
deserved.

I do think that it's bad that SQL storage feature lacks a definition for
the flavor of SQL used and a forward-compatibility story for evolving
the flavor.

I don't think it is right, either.

However, not having a Hixie-quality spec even for the database API would
be worse than having the API specced. To a large extent this is an issue
of how much interim (well, hopefully interim) 'not right' one is willing
to tolerate when the realistic alternative would mean unspecced things
getting added to sides of implementations of the interoperable platform
if other competent and willing editors aren't stepping up.

I'm not asking you to name names here, but is there a concrete reason on
the level of knowing a potential person to believe that another editor
would have stepped up for the SQL part if the API part weren't in a
'holding pattern'?

There is precedent to successful (XHR) and unsuccessful (window object)
spec splitting in the context of HTML5 when editors have stepped up.

Also, it seems to me that while the situation is largely about editors,
it's also about the overhead of getting copyright and patent policy
sorted out if a given passage of text goes into a new deliverable
instead of going into a catch-all existing one.

This raises the question of what things *should* be accredited by HTML5.
Can we come up with criteria that isn't awfully subjective and that
doesn't generate into doing merely an HTML 4.1? I think disagreeing so
much that all that's left is roughly an HTML 4.1 would be a huge PR
blunder now that HTML5 is enjoying positive buzz to the point that HTML5
represents all the cool new things--so much so that once in a while new
features that haven't, in fact, ever been in any HTML 5 draft get
characterized as "HTML5 foo". (I tried to search for an example of
someone saying "HTML5 Selectors API", but I couldn't find it any longer.)

That said, I agree with your point on the level of principle. However,
in practice, it is a problem if vendors have more willingness to
implement and ship than to contribute editors for the features they
ship. That is, I don't think it is a satisfactory solution to leave
things unspecced when a vendor willing to ship isn't contributing an
editor also.

But yeah, such failure to contribute an editor should probably not be
rewarded by having things fall under the HTML5 brand as the *fallback*.

Now we also have a new case to study. There's a different Hixie spec
that wasn't edited under the HTML5 brand: Web Workers. It was also
driven by a couple of first-mover vendors, although in this case Mozilla
was one of them. Perhaps it would be useful to analyze what went right
and what went wrong about Workers and then use this data to develop a
better mode of working for new platform features whose dependencies are
mostly around the security model and window object general area.

I observe that the spec got the the point of implementations being
roughly ready to ship at the WHATWG before the W3C Web Apps WG managed
to perform enough of a charter dance to get the spec under the W3C
Patent Policy.

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

In article <dZydnXfs1q2OdwPUnZ2dnUVZ_q_in...@mozilla.org>,
 Boris Zbarsky <bzbar...@mit.edu> wrote:

Which leads to a situation of having multiple potentially contradictory
specs to read that cover the same feature.

Perhaps my outside view of the group isn't perceptive enough to make CSS
a relevant example.

I think it's a problem if it's not obvious. Do you have suggestions on
how to make it more obvious?

(At least here, the delay before the annotations show up is rather
large.)

That depends on how much attention it takes from the rest of the group.

Personally, I'm also concerned about whether publishing a HTML "4.1" or
somesuch would result in demand for more validation targets in
Validator.nu.

Perhaps "political" isn't the right word, but the concern about who gets
to use the HTML5 brand for marketing what and how executive and board
overlaps are relevant to this question doesn't seem like a technical
issue to me.
http://groups.google.com/group/mozilla.dev.platform/msg/adaf80378662ea08

I meant asking about stability when deciding what to implement next. I
didn't mean that IRC should be used as a preferred mode of information
transfer when implementing a given feature.

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

In article <499F25F9.1010...@inkedblade.net>,

I think it at least somewhat a problem if a reader needs to cross-check
which parts of a given CSS3 module are also in CSS 2.1.

Having multiple separately edited releases of HTML with syncing failures
is something that I think the HTML WG should avoid.

Sure, there are large intertwingled areas. However, in the case of CSS,
each selector is pretty much an independently trackable feature. Also,
many properties or many smallish groups of properties are for practical
purposes independently trackable features.

In HTML5, <canvas> and <video>, for example, can very well have their
stability/maturity tracked individually.

I guess the issue of having a monolithic spec or having multiple modules
is something that doesn't have an objective right solution. As an
editor, you say that modules work better for you. Hixie says a
monolithic spec works better for him. As a reader, prefer loading the
single-page version of HTML5 into a browser window over having to open
multiple CSS3 modules or having to navigate across multiple pages of SVG
1.1 spec. (In the case of SVG 1.1, I tend to prefer the single-file PDF
over the multiple HTML files!) However, many other readers dislike the
single-page version of HTML5 and prefer the multi-page version.

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

On Feb 22, 8:08 am, Henri Sivonen <hsivo...@iki.fi> wrote:

That is a very roundabout way of saying "stop". I'm not saying Ian
should stop.

With time, it will be clear which documents will be able to progress.

- Rob

In article
<a974f5dc-2b2a-4045-bff2-24a931f94...@v39g2000yqm.googlegroups.com>,

I'm not trying to be roundabout here. Also, I'm not trying to
communicate with terms like "stop".

You haven't been very forthcoming about your intentions regarding your
draft (as opposed to referring to what others have said). Without
knowing which direction it is supposed to go and why, in the plan of the
person who produced it, it is effectively a Rorschach test that elicits
projections of feelings about how HTML5 has been developed and perhaps
even about other previous interaction with Hixie.

I explored the plausible space of where your draft might be headed, and
stated that I think one of those plausible directions should be avoided
in my opinion.

If you read this as me telling you to stop, I conclude that positioning
your draft as a separately-edited HTML WG release of HTML with potential
syncing failures is indeed a direction you are considering as a possible
way forward.

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/