Re: HTML5 script start tag should select appropriate content model according to src

Tina Holmboe wrote:
>    * Presentational elements are kept. This includes the HR element,
>      SMALL, B, and I. This is 2007; NONE of them should be kept.

No comment on this because I'm steering clear of the perpetual debate 
about <b> and <i>.

>    * 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.  There are multiple ways in 
which this could be presented.  e.g. coloured background, underlining, 
bold, etc.  The element itself doesn't describe presentation, only it's 
purpose.

Its definition will be revised in due course.  It has been discussed and 
you are not the only one confused about its meaning.

>    * Elements with previously defined semantics have been changed, such
>      as CITE: "The cite element represents a citation: the source, or
>      reference, for a quote or statement made in the document."

I do not understand how the meaning of cite has changed significantly 
from HTML4, which states:

   CITE:
     Contains a citation or a reference to other sources.

The definition in HTML5 just seems to refine that definition.

> WHERE in the document? Specify much, much sharper.

In the definition for blockquote, it states:

| If a blockquote element is preceeded or followed by a p element that
| contains a single cite element and is itself not preceeded or followed
| by another blockquote element and does not itself have a q element
| descendant, then, the citation given by that cite element gives the
| source of the quotation contained in the blockquote element.

Does that answer your question?

http://www.whatwg.org/specs/web-apps/current-work/#the-blockquote

>    * Elements with no particular structural purpose are added, such as
>      CANVAS, VIDEO and AUDIO. See EMBED. What do we need ANY of these
>      when we can use DIV and OBJECT for the same purpose? Toss out.

Canvas, video and audio provide specific APIs that make them very useful 
to scripts.

Canvas is just like img, except that it is drawn dynamically using 
script.  It has clear usecases, such as drawing graphs from data in the 
page, games, or artwork.

For example:
http://www.abrahamjoffe.com.au/ben/canvascape/
http://www.liquidx.net/plotkit/
http://annevankesteren.nl/2006/05/canvas-3d
http://cow.neondragon.net/stuff/reflection/

Video and Audio are designed in a way that can compete with flash. 
Using object is not appropriate because it would require overloading it 
far too much, introducing APIs that are dependent on the content that is 
loaded and make it impossible to implement.  That would only make things 
worse.

>    * Several ideas added which MAY be good - such as PROGRESS - lack
>      maturity as it is today. Specify far better, and remove the bits on
>      it being 'indeterminate'.

The progress API was designed by studying the progress bars found in 
Windows, Mac and Linux.  Those progress bars do have indeterminate 
states.  If this API didn't, that would be a limitation.  I do not 
understand why you object to that state.

>    * Elements from HTML 4 which have known accessibility issues, such as
>      IFRAME, are kept.

There is nothing inherently inaccessible about iframe, though, like 
anything, it can be used in inaccessible ways.  It provides a nested 
browsing context and is much more interoperable than object is, when 
used for the same purpose.

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

Why?  <embed> is much more interoperably implemented for embedding media 
that requires plugins.  Browsers need to support it in the real world 
regardless of what the spec says anyway, so removing it would do more 
harm than good.

>    * Elements which DO contain semantics - even if rarely used - are
>      being tossed out, such as ACRONYM. Why did you remove that?

In reality, the <abbr> and <acronym> are synonymous with each other. 
Amusingly, the HTML4 definition for <acronym> does not match the actual 
defintion of acronym.  However, not surprisingly, authors use them 
interchangably, and there is no point retaining 2 elements that serve 
the same purpose.

http://lists.w3.org/Archives/Public/www-html/1997Jul/0558.html

It will be defined in the spec in due course, but whether or not it will 
be considered conforming is not yet determined.  I do not think it will 
be, but if it is, its semantics will be identical to <abbr>.  This is a 
pragmatic decision based on accepting the reality of the situation, 
instead of hanging on to an impractical ideology.

>    * The entire specification talks about "applications"; we need a
>      *markup* language, not mix the metaphors. If an application
>      language is needed, XUL and others exist and should be kept
>      carefully away from the document/data markup.

The reality of the situation is that HTML is used for a wide range of 
purposes beyond simple documents.  Web applications are a very real use 
case that can be seen in the wild.  Applications like web mail, online 
stores, games, and much more are being created every day using HTML. 
Why fight against that?  It is much more practical to enhance the 
language to make that easier, than try and force them to switch to a new 
development platform.

>    * Some elements are defined very, VERY loosely - such as 'ASIDE'.
>      What does " ... content that is tangentially related to the content
>      around the aside element ... " mean? 'Around' how? How many lines?
>      Same section? Several sections? Specify better, or remove.

It may be possible to clarify its definition, but there is no need to 
remove it.

>    * FONT. Need I say more? Editors are to use it, browsers are to
>      ignore it? Get rid of it.

As I said in a previous post, this is a very much disputed section.

>    * Attributes are added which have dubious value, such as
>      oncontextmenu and ping. No, users don't want authors to fiddle with
>      context menus or ping anything. Just /keep that out/.

HTML5 enhances the <menu> element in a way that can be used for 
declerative context menus.  This is better than the existing JS based 
approaches that are seen in the wild because the UA can still give the 
user ultimate control.  Depending on the implementation, the UA may use 
the <menu> to augment the existing context menu, or make the native 
context menu available via some other means.

The oncontextmenu attribute is just another useful even that scripted 
applications may make use of for a variety of purposes.

The ping attribute doesn't really provide any new functionality, sites 
have been tracking users for years using a variety of other techniques. 
  It just provides a way to separate the final destination from the 
notification.

>    * Attributes are not removed which should be - target specifically.
>      No, we don't need targets. This is a markup language, not something
>      which define windows to be opened. Take the target attribute out.

The target attribute is required for use with iframes.  I don't like 
that it retains _blank as a conforming value (though it needs to be 
documented anyway), though I have no problems with other values that 
don't create popups.

>    * Oh, and /please/ separate the *markup specification* from the bits
>      and pieces of how to communicate over Bluetooth and irDA ... what
>      has the content of 6.3 to do with HTML? Take it apart; it's too
>      large - 372,900 bytes of markup, DOM, scripting, and who knows what
>      in ONE document that should specify the markup alone is far too
>      much.

Why should it be restricted to just markup?  There are parts of the spec 
that are dependent on other parts.  e.g. The parsing section is 
dependent on document.write(), innerHTML is dependent on the parsing 
section, the video and audio elements are dependent on the 
HTMLMediaElement API, etc.

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.

>>> At this point in time I suggest we start with 4.01 Strict,
>> HTML 4.01 is extremely poorly defined, it is not interoperably 
>> implemented and does not reflect reality.  Why would it be a better 
>> start than HTML5?
> 
>   This might be because not all of us agree that HTML 4.01 *IS* poorly
>   defined. Frankly I consider it less poorly defined than WA1.

Ha!  Pick any section at all in HTML4 that is better defined than the 
equivalent section in HTML5.

For example:

* <strong>, <em> and other inline elements are much more well defined in 
HTML5.
* The definition and processing model for headings is much more well 
defined in HTML5.
* Parsing requirements are virtually non-existent in HTML4.
* <object> is so poorly defined in HTML4, it is yet to be implemented 
correctly by any browser.  This is not just because they are lazy or 
anything like that, it's because it is far too complex and yet very much 
undefined.
* There is no error handling defined in HTML4, there is in HTML5.

Need I go on?  Let me know if you have any specific sections in mind 
that you think are so well defined in HTML4.

>   Perhaps we should create a user-driven group that can take on the task
>   of cleaning up HTML 4, and present that as an alternative. The HTMLWG
>   would, I presume, give that equal consideration.

You are free to join the HTMLWG, do the necessary work and put forth 
that as a proposal if you wish.

-- 
Lachlan Hunt
http://lachy.id.au/

Received on Thursday, 26 April 2007 04:00:34 UTC