Re: [whatwg] Empty elements
On Sun, 28 Aug 2011 19:45:50 +0200, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 28.8.2011 17:52, Aryeh Gregor wrote: Void is correct: http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#void-elements I see. What a pointless and confusing change (from HTML tradition and SGML usage). Empty is descriptive (an element that has no content, or has empty content), whereas void suggests associations like null and void or void pointer. This is about elements that are very real and meaningful, instead of being void in any normal meaning - they just express everything they can express by their name and attributes p/p is an empty element since it has no content, but p is not a void element. Maybe void isn't a great term, but empty isn't either. Documents served with a text/html MIME type must obey the HTML syntax rules, not XHTML. I couldn't find where the spec says this normatively, but there's an informative note at the top of the HTML syntax and XHTML syntax sections. So does this mean that the rules are, after all, different for HTML serialization than for XHTML serialization? After all? They have always been different... If you're serving a document with an XML MIME type,foo/foo is equivalent to foo / for any value of foo. The validator won't distinguish and neither will UAs, so use whichever you please. They're entirely different with an HTML MIME type, and that cannot be changed at this point due to compatibility. Is there any way to tell validator.nu or the W3C Validator in HTML5 mode to apply XHTML rules when submitting a document via a text field or via file upload? In http://validator.nu/ you can choose XML or HTML under Parser. Is there any requirement on such a distinction? About what? When validating via URL, the W3C Validator (in HTML5 mode) indeed accepts p / when Content-Type: application/xhtml+xml. However, validator.nu responds: IO Error: Non-HTML Content-Type: application/xhtml+xml. This is getting rather confusing... I guess you chose the HTML5 parser in validator.nu, which will not accept an XML MIME type (you need the XML parser for XML). I think the W3C validator doesn't have a way to choose between XML and HTML in HTML5 mode, it will decide from the MIME type (dunno what it does for file upload). -- Simon Pieters Opera Software
Re: [whatwg] Empty elements
29.8.2011 13:10, Simon Pieters wrote: In which way is void better than empty? The sentence p/p is an empty element since it has no content, but p is not an empty element. is more confusing. More confusing than what? (Is that hypothetical sentence more confusing than p/p is a void element since it has no content, but p is not a void element.?) Previously, empty element was used as a technical term, and p/p was not called an empty element. If somewhat calls it that way, doesn't that just call for a correction and a pointer to a definition, rather than changing the term? -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Empty elements
On Mon, 29 Aug 2011 12:17:29 +0200, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 29.8.2011 13:10, Simon Pieters wrote: In which way is void better than empty? The sentence p/p is an empty element since it has no content, but p is not an empty element. is more confusing. More confusing than what? More confusing than: p/p is an empty element since it has no content, but p is not a void element. (Is that hypothetical sentence more confusing than p/p is a void element since it has no content, but p is not a void element.?) No. Previously, empty element was used as a technical term, and p/p was not called an empty element. It seems reasonable to call it empty. It matches XML's definition of empty. http://www.w3.org/TR/xml/#dt-empty If somewhat calls it that way, doesn't that just call for a correction and a pointer to a definition, rather than changing the term? empty is both a loaded word in that people think that p/p is empty, and XML's definition of empty matches that. I think it's reasonable to try a different term for the void element concept. -- Simon Pieters Opera Software
Re: [whatwg] Empty elements
On 29.8.2011 12:17, Jukka K. Korpela wrote: 29.8.2011 13:10, Simon Pieters wrote: In which way is void better than empty? The sentence p/p is an empty element since it has no content, but p is not an empty element. is more confusing. More confusing than what? (Is that hypothetical sentence more confusing than p/p is a void element since it has no content, but p is not a void element.?) Previously, empty element was used as a technical term, and p/p was not called an empty element. If somewhat calls it that way, doesn't that just call for a correction and a pointer to a definition, rather than changing the term? Hi, it is not confusing at all, empty element is an element with no content (p/p), void element is element that can have no content... the difference is clear, but yes... void is not the best name Brona
[whatwg] Terminology: managed vs. manual transactions
In the UndoManager spec http://rniwa.com/editing/undomanager.html, there are two types of transactions: managed and manual. Managed transactions are handled by the browser, while manual ones are handled by the author. The term managed keeps confusing me, though. I never remember if it means managed by the browser, or by the author. Why don't you rename managed transactions to automatic transactions or something like that?
[whatwg] Node inDocument
As we were looking at mutation events we realized that we would like to expose whether a Node is in the document or not. Both WebKit and Gecko have an O(1) way of determine this. Today, to do this in script this is O(depth) which is clearly sub optimal. We are therefore suggesting adding the following to Node idl: readonly attribute boolean inDocument; Has this been covered before? Is there a reason why we would not want to do this? erik
