Re: Short-term workarounds - - <source> in <video>

>>>. After I sent the reply, I started to realize what you meant by
>>>pointing to boolean attributes as a parallel issue:

>>>> Whenever one inserts a unknown attribute in a HTML element, and
>>>> even if you do not intend it as a boolean - e.g. <div
>>>> myBoolenan>, still, in the DOM, it becomes mybolean="" or
>>>> myboolean="myboolean".
And I assume XHTML compatibility requires the myboolean="myboolan"
form as well.

>>>>  That's why HTML 5 permits boolean attributes in all 3 variants
>>>> above.

Thanks for thinking more about that.
So these are just the maybe best examples of how a browser for html is
more simple than a browser for Xhtml,
In html, the browser can make a few gueses about content structures
and authors's intent, so some syntax is relaxed and stuff makes
pixels.

One example is using this html 'void' element, like head <meta ... >
items,  nested elements in <object>. <video>, <audio>, <command> and
others like <hr>.
My second thought on this was to ask whet the feck anyway? WHy is this
so potentially confusing and what is that workaround, really. And what
is this void element item that never can become xml.
Ooh, well this decends from <meta name='string1' value='string2'>
which holds stuff that if not really content anyway so, for
simplicity, metas don't have to be complicated by using that pesky /
like in xml.

So it goes to when this concept was worked around for object, to just
use simple name value pairs and really, the <param>s are not really
content to be dealt with by the main parser. For html, the void is a
subset of empty that allows the html author to drop the / normally
required to close an empty element.
To author Xhtml, the normal / to end the empty element is required.

>> Introduce a new class of transitionally valid features - aka a
>> pre-obsoleted/planned obsolete class? [1]

Another alternative is dropping the idea of a void element. It or any
of the maimed variations are legal for legacy because the text/html
browser knows how to handle it, Just that for preferred html5 and
Xhtml, these and all like them are treated as empty.
One reason to do this is that "void" workarounds don't exist past html
served as text/html.
In the xml case application/xhtml+xml it is an empty element. This is
becasue there is not a thing such as a void element in XML and thus is
this not possible in XHTML.

For text/html, where the browser can make guesses and make maybe do
some processing that is special, let them do whatever, apparently,
while for Xhtml the browser is not supposed to guess at the author's
intent and the syntax is fixed by (more) exact definitions and
documentation (dtd/schema namespace) that must be followed.

So, <param ... > in html is legal because the browser accounts for it
as a special (void) case.
While in Xhtml if you have an empty element, then you are supposed to
close it, I think with a space/> so for XHTML, you need the xmlized
<param ... />.

In XHTML I would hope the parser is smart enough to give an error when
a structure like <param ...></param> is encountered nested in an
<object>, for instance, if param is specified as an empty element. It
should not pass unless the schema gives it both ways and it can't that
I think.

So the alternatives exist on text/html not in application/xhtml+xml.
In html it will mess something up, I am sure, but missing the closing
/ and treating these few elements it as html hard-code "void" is not
too bad, just slightly confusing.
And, like meta, learning about void is void, as ffar as I know, when
you get to XHTML.

How do I know if it is html or xhtml?
I hope it is just as simple as telling the server how to serve it and
we neglect any metas for type in the html or html or xhtml and follow
what the server says it is.

Thanks Again and Best Regards,
Joe





because

THese are simple
mistakes on interpretation,

----- Original Message ----- 
From: "Leif Halvard Silli" <xn--mlform-iua@xn--mlform-iua.no>
To: "Maciej Stachowiak" <mjs@apple.com>
Cc: "Joe D Williams" <joedwil@earthlink.net>; "Tab Atkins Jr."
<jackalmage@gmail.com>; "HTMLWG WG" <public-html@w3.org>
Sent: Sunday, October 25, 2009 6:11 PM
Subject: Re: Short-term workarounds - - <source> in <video>


> Maciej Stachowiak On 09-10-26 00.28:
>
>> On Oct 25, 2009, at 4:25 PM, Leif Halvard Silli wrote:
>>> Leif Halvard Silli On 09-10-25 00.34:
>>>> Maciej Stachowiak On 09-10-24 01.27:
>>>>> On Oct 23, 2009, at 3:41 PM, Leif Halvard Silli wrote:
>>>
>>>>>> Why can't HTML 5 permit that?
>>>>> I think it would be reasonable (and perhaps on balance a good
>>>>> idea) to  allow a close tag for new void elements. Though it
>>>>> would  have to  immediately follow the open tag - a close tag
>>>>> separated  by content  would have to be treated as just a stray
>>>>> close tag and  a parse error.  Otherwise the open tag alone
>>>>> wouldn't work, since  you would have to  parse to the end of the
>>>>> document to know if  there is a close tag.
>>>> Sounds reasonable! Filed a bug report for the issue [1] including
>>>> a  Liv DOM Viewer demo of browser behaviors [2].
>>>> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8038
>>> There is also the option of making closing tags for void elements
>>> "obsolete but conforming".
>>
>> I don't think "obsolete but conforming" is the best choice - we're
>> talking about a new construct that authors would use to help them
>> transitiion, not an old feature that is ok in older content but
>> should  be phased out in new content. Thanks for filing the bug, by
>> the way.
>
>
> All new (= unknown) elements are expected to have closing tags. Thus
> it is possible to claim </source> to be obsoleted, I think.
>
> I can see one bad thing with "obsolete but valid" for "</source>":
> authors could perhaps be made to think that this feature -
> "</source>"  - isn't necessary anymore.
>
> What alternatives are there, if the point is solely to help authors
> to transition? Introduce a new class of transitionally valid
> features - aka a pre-obsoleted/planned obsolete class? [1]
>
> [1] http://en.wikipedia.org/wiki/Obsolete#Planned_obsolescence
>
>>> I think it would be possible to have such a rule for *all* void
>>> elements - not only the new ones - as user agents deals with
>>> things  like <img></img> anyhow.
>>
>> Yes, but I don't think there is ever any reason to write
>> <img></img>  instead of <img /> or <img>.
>
> It would align the syntax more with XHTML. And one could claim that
> such a rule would simplify the rules. But I see your point.
> -- 
> leif halvard silli
>

Received on Monday, 2 November 2009 20:04:01 UTC