HTML5 in W3C public CVS! Web Applications 1.0 has been renamed to HTML5 and it seems the e-mail flood on public-html@w3.org is calming down for now. Meanwhile we now have 409 participants in the HTML WG. Next steps are review of HTML5 by the HTML WG and putting down some requirements for the future of forms with the Forms WG as I understand it.
By the way: Anyone know a good location for a WHATWG party?
Fantastic!
I just (finally) joined yesterday. Looking forward to catching up and seeing where things will go!
I was curious what is going to happen with boolean attributes (for the XML syntax): e.g checked="checked". (I don't really want to get on the list as this is my only issue with html5)
I use XSLv1 to output/pregenerate XML (XHTML) that is sometimes used further down the line as the input for a scripting runtime (I usually use apache's velocity as it seems most XML friendly). It is inconvenient/ugly to deal with boolean attributes. I would love to be able to write something like:
<input type="checkbox" checked="$page.inputsBooleanValue"/>
I can not comfortably control the XSL transform to produce:
<input type="checkbox" #if ($page.inputsBooleanValue) checked="checked" #end/>
(and doing an if..else and writing the input elem twice, one with the checked @ and one without, seems wrong)
I have tried looking around for some answers and the closest I could find was on an opera dev list:
http://dev.opera.com/forums/topic/169941
I have asked about this issue before on the old w3 html list:
http://lists.w3.org/Archives/Public/www-html/2005Mar/0046.html
Couldn't the old SGML way be preserved but but also allow boolean attributes to have boolean values?
The W3C is opening their offices in South Africa on 14 May 2007 so if the party can wait for a few days we can hold a massive bash (the event kind, not the *nix shell kind) in Pretoria if you guys are willing to fly all the way down to the southern tip of the African continent. :)
Rob Koberg: I think the issue regarding using "true" or "false" in an attribute that supports minimization is that legacy user agents will trigger on whether the attribute is present rather than what the value of the attribute actually is. For instance, if you have |disabled="false"|, then the form control will be disabled. Because the mere presence of the attribute causes browsers to treat it's value as true, you have to do this:
<input type="checkbox" #if ($page.inputsBooleanValue) checked="true" #end/>
That really isn't much better that your earlier example:
<input type="checkbox" #if ($page.inputsBooleanValue) checked="checked" #end/>
Now, in theory, we could just avoid attribute minimization in new boolean attributes and make them default to false when you don't declare them. Another thing we could do is could require attribute values to be either the name of the attribute or "true" in order to make the attribute true, but that requires additional parser complexity. In both cases, the value of "true" is inconsistent with how existing boolean attributes work in HTML. It would appear that the HTML5 solution is the best in this case.
On a side note, I think that the lack of attribute minimization is one of the principle motivations behind the |role| attribute. What are roles other than a series of boolean values assigned to an element?
I would love to be able to write something like:
<input type="checkbox" checked="$page.inputsBooleanValue"/>I can not comfortably control the XSL transform to produce:
<input type="checkbox" #if ($page.inputsBooleanValue) checked="checked" #end/>(and doing an if..else and writing the input elem twice, one with the checked @ and one without, seems wrong)
<input type="checkbox">
<xsl:if test="$page.inputsBooleanValue">
<xsl:attribute name="checked">checked</xsl:attribute>
</xsl:if>
</input>
Aristotle:
I use XSL to pre-generate the runtime template page. XSL is not used at runtime.