Re: Spec with issue markers [was: Re: HTML5-warnings - request to publish as next heartbeat WD]

> Sam Ruby wrote:
>>> Can someone give a link that lands close to one of these so I can 
>>> be
>>> sure what I am looking at?
>>
Sam Ruby >> http://dev.w3.org/html5/spec/Overview.html#video

Thank You, now I see. That is nice. Outbound links?
(I guess my comments still stand for *Warning!(s) elsewhere in the 
text. )

Also thanks for the link into the Embedded content topics.
I think that category of interfaces will turn out real nice and be 
very useful for a long time.

manu > I'm thrilled to see these status markers
in the published W3C spec.
> Great job to those that participated and made this happen!

I agree. Happy to see status of Working draft for some important 
points.

>
> Many thanks to James Graham for modifying Anolis to make this 
> proposal
> less controversial, and thus, a reality. :)

I suspect this is not a done deal and still needs to be shown to work 
by being responsive long term, keeping a good history, and allow the 
document to remain live and under editorial control.

Speaking of editorial control, I still think
4.8.4 The embed element
now in Working Draft needs to be removed from this main list and moved 
to be obsolete.
I see the bug 7075 is stopped due to given opinion that <embed> 
doesn't do any harm. Still, I respectfully disagree now more than 
ever.

Now let's look at this again and decide that <embed> then-innovative 
and then-important although ill-specified and documented element msut 
not even be considered for support in HTML 5. Sure, old browsers can 
do it if they think they need to, but support shall be optional.
It will be possible for an author to find out that <embed> is not 
supported in HTML 5 by using an HTML 5 validator. Any authoring tool 
can produce the <object> element and supporting <param> pairs to 
replace any <embed> element. In fact, for certain media, the tool 
might generate to <audio> or <video> elements. So absolutely dropping 
<embed> will be better and more fun for everyone involved.

With added depth in the discussion of <canvas> we can also see an 
important detail.

If <canvas> is actually presenting any problems with fallback and/or 
interpretation by alternative user interface requirements, then 
<embed> is totally impossible.

Thank You and Best Regards,
Joe

Received on Monday, 24 August 2009 21:26:43 UTC