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

On Wed, 25 Apr 2007 12:17:11 -0400, Tina Holmboe <tina@greytower.net>  
wrote:

>> Why isn't it good enough?  Could you be a little more specific about
>> what is wrong with it?
>
>   More specific? Very well.
>
>    * Presentational elements are kept. This includes the HR element,
>      SMALL, B, and I. This is 2007; NONE of them should be kept.

They are kept for reasons of interoperability, mostly.  If the definition  
of these elements are not specified anywhere yet are nevertheless widely  
used in the wild, how can we possibly achieve interoperable results?

>    * Presentational elements are ADDED. M, anyone? This is the realm of
>      CSS; discard.

<m> is not, from what I understand, presentational.  Its semantics -are- a  
little shaky right now, sure, but last I checked it was used to  
distinguish an arbitrary run of text from its surrounding text.  That's  
not presentational.  I'm not aware of any other so-called presentational  
elements being added.

>    * 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." - WHERE
>      in the document? Specify much, much sharper.

So?

>   * 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.

<object> is notorious for being virtually impossible to implement  
properly.  As for whether we need <video>, <audio> and <canvas>, I am  
personally ambivalent on the matter.

>    * 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'.

This is why the spec is still a -DRAFT-.

>    * Elements from HTML 4 which have known accessibility issues, such as
>      IFRAME, are kept. Elements that were never IN HTML - such as EMBED
>      - are included in the spec! Get rid of both.

See response to first point above.

>    * Elements that are almost never seen in the wild ARE kept, such as
>      KBD. Keep, that's fine, but then there is NO need to remove
>      ACRONYM.

Ditto.

>    * 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.

See earlier point about this still being a draft...

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

Need -I- say more?

>    * 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/.

I believe the rationale there is in fact very user-centric.  In short,  
authors -do- want to ping, and they -will- do so however they can, even if  
they have to resort to user-hostile methods.  This situation exists right  
now.  The ping attribute, anyway (I have not looked at |contextmenu|), is  
a convenience to users so that they can still know unambiguously where a  
hyperlink is taking them, while still allowing authors to ping third-party  
resources as easily as they can now.

>    * 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.

Again see first point.

>    * 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.

The spec is apparently easier to edit as one document.  My understanding  
is that it will be split up in due course.  There is also nothing stopping  
sections from being re-organized fdor clarity sometime down the road.

>> Do you realise how much time we would waste by starting with HTML4 and
>> removing/replacing with features from HTML5, just to end up with a
>> spec equivalent to the HTML5 spec we have now?  A much better
>
>   No. We are wasting time by discussing WA1 when we could improve on
>   HTML 4.01 instead.

This is precisely what WebApps does, for the most part.  It adds features,  
yes, but a -large- part of what it does is simply clarifying HTML 4.01.

>   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.

Er.... have fun, then?


To summarize, no one is suggesting that WebApps is a complete, finished  
and polished specification.  Lachlan Hunt and others are simply suggesting  
that it is a solid basis for future work and discussion.  HTML 4.01 would  
also be a possible starting point, but when compared to WebApps, the  
latter already fills in most of the critical gaps (notably parsing), so  
where's the advantage?

As may be evidenced by the fact that I did not reply to all your above  
points, Tina, I do not disagree with all of your arguments, myself.   
WebApps goes a little too far in some respects, I think, but I still think  
it's worth something, and definitely an excellent resource as far as  
documenting how HTML works in the real world.

-- 
J. King
http://jking.dark-phantasy.com/

Received on Wednesday, 25 April 2007 17:08:32 UTC