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

On 25 Apr, J. King wrote:

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

  In that case we not only can, but MUST, apply the same logic to
  FRAMESET. If presentational element FOO is included for
  interoperability, then there is no logical reason to exclude
  presentational element BAR.




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

  Arbitrary run of /which type of/ text? At the moment all the M
  definition say is "... a run of text marked or highlighted."

  That is undoubtfully presentational only. If it was called <result>
  and meant to be used to illustrate search terms showing up in a page,
  sure. If it was meant to illustrate *highlighted*, arbitrary, pieces
  then we've got EM for that purpose.





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

  So ... it needs to be shaped up. This is one of several issues I've
  raised, on request, after an hour's work. The way the CITE element is
  used, for instance, combined with the definition, makes it impossible
  to programmatically determine where it was supposed to go.





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

  Then we fix it.




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

  Exactly. This is why I am bitching - it's a draft, and it is too loose
  and early an draft to be used as the basis for the HTML5 spec.

  So don't point implementors that way, or we'll end up with UAs that
  implement CANVAS before the rest of us agree it's a good idea. (That's
  sarcasm, yes)




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

  I'd hope not. I *sincerely* hope that the W3C will not touch with a
  ten foot pole ANY 'draft' that contain FONT.




> 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

  That's actually the opposite. The concept that "Authors will do
  idiotic things, so we'll make it easier for them" does not translate
  into 'user-centric'.

  Adding yet another feature that will need an easily reached control to
  be disabled is really a waste of time - and it has NO place in a
  specification that is a *markup language*.

  The cards are getting mixed.




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

  But it's not. It's not clarifying HTML 4.01 /at all/, which my list of
  points clearly show.




> 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

  And I, and others, disagree. It's /not/ a solid basis. That is the
  topic of this entire discussion.




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

  The problem with that is clear. The way HTML 'works' in the real world
  can be replaced by DIV, SPAN, CSS and a jumble of JS. It's really
  rather the wrong approach.

  That is not to say - and I have never said - that WA1 doesn't contain
  bits and pieces that may be very useful. The way it looks today is
  just not a go.

  It is my hope these concerns will not be either scoffed at, or
  ignored.

-- 
 -       Tina Holmboe                           Greytower Technologies
       tina@greytower.net                      http://www.greytower.net
        +46 708 557 905

Received on Wednesday, 25 April 2007 17:43:33 UTC