Adopting WHATWG work as a base for work by the new HTML working group (was Re: HTML5 script start tag should select appropriate content model according to src)

Lachlan Hunt wrote:

>>    * Presentational elements are ADDED. M, anyone? This is the realm of
>>      CSS; discard.
> 
> <m> is not presentational, you just misunderstand its purpose.  It
> indicates relevance in a given context.

The specification doesn't say that. It says "marked or highlighted".
That is presentation.

> Its definition will be revised in due course.

... but right now, it is presentational.

>>  Elements that were never IN HTML - such as EMBED  - are included in the
>> spec! Get rid of both.

> Why?

Since it has the same purpose as the object element.

> <embed> is much more interoperably implemented for embedding media
> that requires plugins.

Vendors seem to be waking up to standards, perhaps it is about time they
 implemented object better.

> Browsers need to support it in the real world

So they can implement it as a legacy / proprietry feature. It doesn't
need to be kept for moving forward.

> Why should it be restricted to just markup?

* It is a markup language
* Adding non-markup content adds complexity

> There are parts of the spec that are dependent on other parts.  
> e.g. The parsing section is
> dependent on document.write()

Why? Should the parsing section not contain generic instructions for
handling <script> elements that generate inline content through any method?

> innerHTML is dependent on the parsing section,

Why? Should innerHTML not be defined in more generic terms, and not
limited to HTML documents and documents in the XHTML namespace?

> the video and audio elements are dependent on the
> HTMLMediaElement API, etc.

Why? Shouldn't they be defined in terms of the semantics they represent,
and APIs defined seperately?

> Some parts have already been extracted and put into new specs, like
> XMLHttpRequest, but that is dependent on having competent editors
> available to work on those specs.  There is no point extracting a
> section if there is no-one to work on it.

You have people willing to work on that part of the specification if it
is mixed up with the HTML specification, why not in a seperate
specification?

There is a lot of content that has merit in the WHATWG's work, but
adopting it as a base would give it a great deal of inertia. Things that
are "in the spec" are likely to be harder to get changed. Recieving the
entire spec in one go is going to be "information overload" for some
people and it won't get as much attention as it would if the base was a
simpler specification and proprosed changes (many of which could be
along the lines of "Adopt section 1.1 of the WHATWG work") were
presented over time.


-- 
David Dorward                               <http://dorward.me.uk/>

Received on Thursday, 26 April 2007 07:30:15 UTC