Re: [whatwg] Pattern Hint
Ian Hickson wrote: Actually, the way the spec is written now, the UA _can_ assume that the title attribute is going to help. In fact it is encouraged. Assume that your proposal (hint) is spelt title and implement it like that. (Including the little button you wanted for hint). That is the intent of the spec at the moment. There is a certain presumption that the author doesn't want to use |title| for any other purpose than providing input hints. This is potentially erroneous. For instance, the |title| may describe the purpose of the input rather than the input pattern. If someone is inputting a credit card number, it may be to hold a reservation rather than make payment, and the author may wish to communicate that via a tooltip. By making the |title| the semantic method of providing pattern hints, you block the web author from using tooltips for any other purpose, and that's even assuming the user agent won't treat |title| as a special case when applied to form controls.
[whatwg] Re: Simple template-based editing
Lachlan Hunt wrote: Andrew Fedoniouk wrote: Instead of having contentEditable attribute in our rendering engine we've introduced new input element htmlarea analogous to textarea. We had a similar discussion recently on the WHATWG list [1] about contentEditable vs. htmlarea vs. textarea. The general feeling, AIUI, was that textarea accept=text/html and a hypothetical htmlarea element would be semantically equivalent, Initially I believed that, but after some discussion, I realized that textarea accept=text/html has some very serious DOM and CSS issues. and that contentEditable is also needed for different use cases, mostly because, unlike textarea, (1) its content can be styled with CSS and (2) its content can be accessed/manipulated through the DOM interface. And htmlarea element will fit those cases as well. The |contenteditable| attribute is better suited for situations where editability is dynamic, however. For a simple rich editing control, though, htmlarea is superior. For textarea, it's up to the UA to provide the editing environment, whether it be a WYSIWYG type of editor, a textarea with syntax hilighting, or whatever else. Plus the textarea at least falls back to a textarea for UAs that don't provide such editing abilities and is more flexible in that it can accept any type of text input, such as text/*, */*+xml, etc, whereas htmlarea is limited to HTML only. Yeah, textarea has the corner on backwards compatibility. Sometimes I wish HTML had a sort of try/catch functionality: | try id=rich1 | htmlarea[...content...]/htmlarea | /try | catch for=rich1 | textarea accept=text/html[...content...]/textarea | /catch I don't like it, but you can see where I'm going with this...
Re: [whatwg] [WA1] The profile Attribute
James Graham wrote: Most documents on the web are a direct result of view-source style learning. If they're invalid rubbish, it's (at least partly) because spec writers have erronously assumed that the majority of authors would have enough of a clue to check things like whether there were conflicts between diffrent profiles they were using. In fact, the fact that authors won't check for conflicts is one reason that namespaces *should* be used for profiles - and we should encourage authors to use them as much as possible so that every value assosiated with a profile is assosiated explicitly. Authors simply won't read the part of the spec that explains why including multiple profiles is a bad idea, will include multiple profiles (since they'll see that that's allowed from view-sourcing other documents) and will run into name conflicts. So, infact, I'd require that all profiles introduced through a profile element (or similar) have an explicity title that was then required for accessing that profile throughout the document. The profile attribute on head would be discouraged. Then authors looking at a document via view-source would see a consisent and logical picture which they could easilly copy. So what you're suggesting is something like this?... | link rel=profile href=http://gmpg.org/xfn/11; title=xfn | [...] | a rel=xfn:colleague href=http://lachy.id.au/; | Lachlan Hunt: Web Development Guru | /a
[whatwg] [html5] Copyright and licensing metadata
Daniel O'Connor wrote: Ick! XML gave us xmlns for a reason! Failing that.. Seeing as this is a working group for HTML as well as XHTML, and only deals with the HTML namespace, any discussion in the mailing list of the use of other namespaces is pointless. See: http://dublincore.org/ http://creativecommons.org/ http://www.w3.org/2005/Talks/05-steven-xtech/ http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-meta.html http://hublog.hubmed.org/archives/001187.html ... There's far too many more widely accepted methods of inserting metainfomation (in the microformat / RDF + GRDDL / style) into a (x)HTML document without the need for a copyright attribute. Okay, let's look at my example again: | code copyright=2005; Matthew Raymond | license=GPL 2.0; http://www.gnu.org/copyleft/gpl.html; | // * Put non-proprietary code here... | span copyright=2004-2005; Microsoft Corporation | license=GPL Killer; http://microsoft.com/licenses/firstborn.html; | // * Ultra-proprietary, patent encumbered code. | /span | // * Put more non-proprietary code here... | /code Now, remember that we can't use namespaces, because HTML doesn't have them. We can, however, borrow from XHTML 2.0 where it doesn't have namespaces, and we can also use classes and relationships. Here's an idea of what the licensing and copyright metadata might look like using the standards you stated above: | code id=codeblock1 | meta about=#codeblock1 property=dc:rightsholder | content=Matthew Raymond/ | meta about=#codeblock1 property=dc:license | content=http://www.gnu.org/copyleft/gpl.html/ | meta about=#codeblock1 property=dc:datecopyrighted | content=2005/ | // * Put non-proprietary code here... | span id=codeblock2 | meta about=#codeblock2 property=dc:rightsholder | content=Microsoft Corporation/ | meta about=#codeblock2 property=dc:license | content=http://microsoft.com/licenses/firstborn.html/ | meta about=#codeblock2 property=dc:datecopyrighted | content=2005/ | // * Ultra-proprietary, patent encumbered code. | /span | // * Put more non-proprietary code here... | /code I'm assuming that the meta elements apply to the entire document unless you use |about|. If you only assume that the meta elements in the head do that, and that otherwise they apply to the parent, you get this: | code | meta property=dc:datecopyrighted content=2005/ | meta property=dc:rightsholder content=Matthew Raymond/ | meta property=dc:license content=GPL 2.0/ | // * Put non-proprietary code here... | span | meta property=dc:datecopyrighted content=2005/ | meta property=dc:rightsholder content=Microsoft Corporation/ | meta property=dc:license content=GPL Killer/ | // * Ultra-proprietary, patent encumbered code. | /span | // * Put more non-proprietary code here... | /code And, of course, if you want the user to see the license and copyright, you just do this: | code | Copyright meta property=dc:datecopyrighted2005/meta by | meta property=dc:rightsholderMatthew Raymond/meta. | Licensed under the meta property=dc:licenseGPL 2.0/meta. | [...] | /code Of course, if we have to use the |about| attribute to keep metadata from applying to the document as a whole, we might to this: | code id=codeblock1 | meta about=#codeblock1 | meta property=dc:datecopyrighted content=2005/ | meta property=dc:rightsholder content=Matthew Raymond/ | meta property=dc:license content=GPL 2.0/ | /meta | // * Put non-proprietary code here... | span id=codeblock2 | meta about=#codeblock2 | meta property=dc:datecopyrighted content=2005/ | meta property=dc:rightsholder content=Microsoft/ | meta property=dc:license content=GPL Killer/ | /meta | // * Ultra-proprietary, patent encumbered code. | /span | // * Put more non-proprietary code here... | /code I suppose you can also use blockquote, cite and address for improved semantics. The first two, though, don't seem appropriate for copyright and licensing information. The third is a slight semantic mismatch, as it's supposed to be for the author's contact information. Using Dublin Core in |rel| attributes might also be useful, but I think that's limited. End of line.
[whatwg] [wf3] Idea: |copyright| and |license| attributes
Had a quick thought I'd like to share with you. Often times, content from other sources might be inserted into a web page, or you may have situations where you wish people to be able to copy part of the text (such as a press release), but not all of it (such as the website UI and graphics). You may also want (or are legally required) to list the original holder of the copyright. There are also situations where managing copyright information for content is difficult without assistance from software. To resolve these problems, I suggest the creation of two new attributes. The first is |copyright|, which allows a copyright notice to be attached to an element. The copyright is inherited by all descendants, unless a descendant element has an assigned |copyright| itself, which overrides ancestor copyrights. Thus, you can theoretically track any part of a document back to its original copyright owner. The second attribute is |license|. It is inherited in the same way as |copyright|, and provides a name and/or URL to the license for the respective content. Editing software can potentially use the licensing information to determine if certain content can be copied into content under a different license. Here's an example: | code copyright=2005; Matthew Raymond | license=GPL 2.0; http://www.gnu.org/copyleft/gpl.html; | // * Put non-proprietary code here... | span copyright=2004-2005; Microsoft Corporation | license=GPL Killer; http://microsoft.com/licenses/firstborn.html; | // * Ultra-proprietary, patent encumbered code. | /span | // * Put more non-proprietary code here... | /code An editor supporting |copyright| and |license| could warn the author that the GPL Killer licensed content can't be used inside the GPL 2.0 licensed content. Also, if the licenses are common enough, the URLs could simply be dropped: | code copyright=2005; Matthew Raymond license=GPL 2.0 | // * Put non-proprietary code here... | span copyright=2005; Microsoft Corporation license=GPL Killer | // * Ultra-proprietary, patent encumbered code. | /span | // * Put more non-proprietary code here... | /code Well, just a thought. There may be better ways to do this already. Let me know what you think.
Re: [whatwg] [WA1] The a element could be empty
Jim Ley wrote: On 9/2/05, Matthew Raymond [EMAIL PROTECTED] wrote: 1) Why wouldn't you want the content in the element to be inserted by Javascript when the page loads when you can just include the content in markup and hide it using CSS? Not particularly wanting to support the OP's issue - I don't see a problem with the change to the content model of a to require content, it's a good thing. However styling a link to print away is not a good idea, as it means those without css get a link which does nothing, Nothing in a print out does anything. If you're using events like |onbeforeprint| and |onafterprint|, CSS is still good as a fallback for browsers that support CSS but not the events. Then again, the user could just do this: | // Code to prepare the DOM for printing. | window.print(); | // Code to restore the DOM after printing. That's, of course, assuming that window.print() halts the script until it's complete. Then again, if the browser is printing from a static copy of the DOM rather than the DOM itself, it may not matter. I guess it depends on how window.print() is defined and what the implementation does. of course it's still possible with the method in the OP's post that the user gets a nothing link, but that doesn't mean the link existing in the source is a good idea. How many user agents support Javascript but not CSS1? Does Lynx or some other text-mode browser support Javascript? I'll have to look into that... 3) How does your original example even prevent the content from being viewed when printing? I don't think that's the purpose, I think the purpose is to ensure there's not content in the page which is purely behavioural and does nothing when script is not available. Makes sense. Personally, I'm wondering why you want to print from a link at all unless you want to perform a special print operation.
Re: [whatwg] [WA1] The a element could be empty
Simon Pieters wrote: Since that's not actually a link (the href points to the javascript: URL scheme which is an ugly hack), what's wrong with: span id=print class=link/span How is an empty span less harmful than an empty a element without an href attribute? An empty a element is semantically meaningless. By contrast, span is already defined as having no semantics and empty span elements are commonly used for styling purposes. Where the link class may be styled to look like a link with CSS, and then var elm = document.getElementById(print); elm.onclick = window.print; elm.appendChild(document.createTextNode(Print this page)); For keyboard access, you need a tabindex=0 which has no effect in legacy UAs, and you currently can't trigger the click event from keyboard in IE6 or Firefox on a span element. The javascript: URI scheme is a separate issue. If we replace the href with http://example.org/; -- or mailto:[EMAIL PROTECTED], or data:,foo, or whatever -- in my first example, I would still like to use an empty a element in the markup. I don't understand why you couldn't just use styling to make an a element display: inline for screen media and display: none for print media. Inserting the contents into a and establishing an |onclick| event means that you'll have to turn right around and use proprietary events like |onbeforeprint| and |onafterprint| to deal with the extra a element so that it won't be seen when you print. So the questions are: 1) Why wouldn't you want the content in the element to be inserted by Javascript when the page loads when you can just include the content in markup and hide it using CSS? 2) Even if some of your users don't have support for CSS, why would you choose to insert content via Javascript when such inserting doesn't change the fact that you're going to have to remove the content before printing? 3) How does your original example even prevent the content from being viewed when printing? 4) What prevents you from inserting the entire a element into a span? 5) How to you get rid of styling for the a element if all a elements are styled in such a way that they are easily visible even when they have no contents? The bottom line is that you need a much better use case.
Re: [whatwg] What exactly is contentEditable for?
Jim Ley wrote: On 8/30/05, Matthew Raymond [EMAIL PROTECTED] wrote: Oh, I think I get it. You don't necessarily want there to be toolbars and the like, No, I want contentEditable left as is, because not all the use cases and delivered products of contentEditable are applicable to full spectrum HTML authoring, they're limited to elements, no CSS, they're limited in what elements they use etc. A UA toolbar in a textarea accept=text/html would be a great idea. I'd really prefer not to limit user agents in any way. (People will just create plug-ins for the desired functionality anyway.) If IE has the ideal UI, then market forces will naturally lead other UA vendors to follow suit(sp?). Is a simple, straight-forward rich editing control too much to ask for? Absolutely not, but it's not the same thing as contentEditable, it has different use cases, that's all I'm saying, we need both, not just one. I'm actually proposing we have |contenteditable|, textarea accept AND htmlarea, so I don't need any convincing. I just don't think it's wise to make UI decisions for the UA vendors, that's all.
[whatwg] [WF3] The altinput Element
The altinput element is intended to be a possible alternative to my
earlier dataentry element.
The altinput element is a way of accomplishing the same goals as
dataentry while ensuring that the size of a form's elements collection
and the position of controls within it doesn't change between legacy and
WF2 browsers. Rather than the element itself being a form control,
altinput instead performs the following:
* If it has a control with an |id| attribute equal to its |for|
attribute, then it attempts to assign its own |type| attribute value
to the |type| of the specified control.
* If the |type| is not supported, then the altinput acts as nothing
more than a span.
* However, if the |type| is supported, the control has its |type|
changed and the entire contents of the altinput element, with the
exception of specified control, are not be rendered.
The result is that, in most cases, altinput acts almost exactly
like dataentry.
*** Examples ***
Here's a simple example for the three select scenario:
| altinput for=d1 type=date value=2005-02-09
| input type=hidden id=d1 name=d1 /
| select name=d1_day!-- Options --/select /
| select name=d1_month!-- Options --/select /
| select name=d1_year!-- Options --/select
| /altinput
Here's an example for users of jscalendar:
| altinput for=sel1 type=date
| input type=text id=sel1 name=date1 size=30 /
| input type=reset value= ...
| onclick=return showCalendar('sel1', '%Y-%m-%d');
| -MM-DD
| /altinput
*** Pros ***
1. The size of a form's elements collection in Javascript never
changes.
2. The altinput element can allow for a far greater range of legacy
fallback than input alone.
3. Because the |type| is defined in an attribute, altinput can be
used for input types in later specifications, or for
vendor-specific input types.
4. Because the element requires a child form control, it encourages
the use of input alone in simple cases where legacy fallback
needs are minimal.
5. The element is designed only to prevent the presentation of its
child elements. It does not require user agents to delete contents
from the DOM or suppress Javascript execution.
*** Cons ***
1. It's slightly more complicated to use than dataentry.
2. In some situations, you must use a hidden input control as the
target of the altinput element's |for| attribute.
3. It may still inherit some minor issues from dataentry.
Re: [whatwg] What exactly is contentEditable for?
Note: The quoted text has been rearranged for clarity. Ian Hickson wrote: The answers to your questions are [...] On Wed, 24 Aug 2005, Matthew Raymond wrote: For example, are the HTML contents loaded into the DOM? [...]only as text nodes[...] Are they treated like a separate document in an iframe, or are they more like the contents of div contenteditable? [...]no [and] no[...] Do they inherit their styles from the current web page? [...] no. It's just a textarea that can have syntax highlighting or other features, with all that being left up to the UA to decide, just like with text/plain textareas. This means the child text of textarea must be maintained or you can't do a reset for that control. Yes. So, where are the modified HTML contents of the control when it's being edited? In the DOM? In .value (as opposed to .defaultValue). This is _exactly_ the same as for a text/plain textarea. This would suggest that textarea HTML contents need to be in a separate document object. If that's the case, how is styling handled? Does it inherit from the parent document? What would a selector like textarea p do? You seem to be making unwarranted assumptions about this feature. There is _absolutely no difference_, from an authoring or DOM perspective, between a text/plain textarea and a text/html textarea. The difference is _only_ from a UA and user point of view, and only in terms of UI. So, effectively, what you're saying about textarea accept=text/html is the following: 1) The HTML in a textarea is unstyled (at least unstyled by the parent document) unless styles or stylesheets are specified within the textarea contents. 2) There is no way to use the DOM to manipulate the contents of the textarea without using a proprietary UA interface. Well, we already have textarea accept. It's up to you guys to convince UA makers to implement it. :-) With these limitations, no one is going to try to convince UA vendors to implement this. The |accept| attribute seem to be no better than using microformats. You might as well remove the attribute form the WF2 spec. The simple fact of the matter is that, with the version of HTML5 you currently propose, there is no way to submit HTML in the DOM without scripting.
Re: [whatwg] What exactly is contentEditable for?
Anne van Kesteren wrote: Dimitri Glazkov wrote: I was thinking more along of the lines of this: div contentEditable id=mainPageContent ... /div form input name=mainPageContentEdit type=html src=#mainPageContent / /form Perhaps we should allow the 'form' attribute from Web Forms 2 on all elements that have the 'contenteditable' attribute set. That would neatly solve the problem. No, because you'd still be missing the |name| of the control. The |id| is not the same thing as a control name. Also not that you loose stuff like disable, readonly, and a host of new WF2 stuff as well...
Re: [whatwg] What exactly is contentEditable for?
Lachlan Hunt wrote: Anne van Kesteren wrote: From a semantic point of view contentEditable is much better than a textarea hack. contentEditiable is not semantic, it's behavioural and belongs in the DOM interface only, not the markup. Yeah, I think you may have a point. It may make more sense to enable editing of DOM Ranges through scripting rather than putting it in markup. After all, if we're going to be dynamically inserting and removing |contenteditable| all over the place, we're already using scripting. On the other hand, if you have a static block that you're going to edit and submit, an actual control makes more sense, be it htmlarea or textarea accept=text/html. Hmm. IE supports the .contentEditable property, so why not just drop the HTML attribute |contenteditable| and leave the DOM property? Not as good as DOM ranges, but that sounds kinda complicated anyways. Nutshell: Allow .contentEditable, but get rid of |contenteditable|.
Re: [whatwg] Pattern Hint
Lachlan Hunt wrote: Dean Edwards wrote: fantasai wrote: Dean Edwards wrote: http://www.whatwg.org/specs/web-forms/current-work/#the-pattern That is not enough. I wouldn't put something so complex in a tooltip. It would frighten my users. What could be so complex that would frighten users when used in a title attribute, yet wouldn't have the same effect when used in some kind of pattern hint attribute, regardless of how it's displayed to the user? Wouldn't it be difficult for someone to type while viewing the tooltip? When I try it in Firefox, the tooltip disappears as soon as I start typing. Unless the user is being presented with a localized control that displays the output in the pattern they're accustomed to, the web developer is going to need to make the hint viewable continuously. In theory, that could be done with some kind of hint element: | label for=phonePhone:/label | input id=phone name=phone pattern=[Blah, blah, blah] | hint for=phone(XXX) YYY-/hint However, this starts to look way too much like my old format idea really quick: | label for=startdateStart Date:/label | input type=date id=startdate name=startdate | hint for=startdate-MM-DD/hint Hmm... I have to think about this one...
[whatwg] [WA1] Idea: meta attribute
I've been noticing that a lot of metadata gets repeated in the web
pages. For instance, the copyright notice you have at the bottom of a
web page may be repeated in a meta element...
In head:
| meta name=copyright
| content=Copyright copy; 2005 by Matthew Raymond.
In body:
| div id=copyright
| Copyright copy; 2005 by Matthew Raymond.
| /div
This is a pain, because it increases the size of the document
unnecessarily. So, I was thinking that it would be nice if we could just
say that a specific element contains metadata of a particular type.
Here's and example:
| div meta=copyright
| Copyright copy; 2005 by Matthew Raymond.
| /div
The value of the |meta| attribute above is the same as that of the
|name| attribute in a meta element. So the above markup creates the
same metadata as following meta element:
| meta name=copyright
| content=Copyright copy; 2005 by Matthew Raymond.
When you have multiple elements with the same |meta| value, you get a
composite. So the following...
| p meta=description
| This page is a page for fans of
| span meta=keywordsStargate SG-1/span who want to learn more
| about the span meta=keywordsX-303/span, otherwise known as
| the span meta=keywordsPrometheus/span. It also contains
| detailed blueprints for the span meta=keywordsX-302/span.
| /p
...would have metadata equivalent to the following...
| meta name=description content=
| This page is a page for fans of Stargate SG-1 who want to learn more
| about the X-303, otherwise known as the Prometheus. It also contains
| detailed blueprints for the X-302.
|
| meta name=keywords
| content=Stargate SG-1; X-303; Prometheus; X-302
Notice, by the way, that you can actually style based on the |meta|
element value:
| span[meta=keywords] { color: red; }
Well, it's just a thought. Seemed like a good one, thought, so let me
know what you think.
Re: [whatwg] [WF2] Readonly and default pseudoclass matching
Boris Zbarsky wrote: Matthew Raymond wrote: WF2 stands for Web Forms 2. Why would it even define :read-only for non-forms elements? It shouldn't. That was the point of my original mail, which you seem to have missed. The current text is ambiguous -- either it's not talking about non-form elements at all, or it's defining :read-only to NOT ever apply to them. I would like the text clarified to the first interpretation, at which point for non-form elements implementors can do whatever CSS3 UI or other relevant spec says without worrying about it conflicting with WF2. Let's look at the specs again to see if clarification is needed: From CSS3-UI (emphasis added): | Specifically, these new states (except for :default) are provided as a | way to style elements which are in the respective states _AS DEFINED | BY XFORMS_. From XForms 1.0 (emphasis added): | :read-only :read-write -- Selects any _FORM CONTROL_ bound to a node | with the model item property _READONLY_ evaluating to true or false | (respectively). Of course, the CSS3-UI spec then turns around and redefines :read-only to be virtually nothing like the way XForms defines it... | An element whose contents are not user-alterable is :read-only. | However, elements whose contents are user-alterable (such as text | input fields) are considered to be in a :read-write state. In typical | documents, most elements are :read-only. However it may be possible | (e.g. in the context of an editor) for any element to become | :read-write. This redefinition was hostile to XForms 1.0 Appendix F. Anyone using Appendix F to determine how to style XForms when using it in an XHTML document may use :read-only and :read-write in ways that cause unintentional styling of XHTML elements. Granted, this section is non-normative, but as shown clearly above, the new states were added under the pretext of supporting styling for XForms 1.0. Personally, I think CSS3-UI should be rewritten so that stylesheets using the XForms definition of :read-only and :read-write don't break. WF2 should just define which elements are considered read-only form controls in HTML. Instead, Ian has sadly chosen to change the text to this: | Matches form control elements that have the readonly attribute set, | and to which the readonly attribute applies (thus radio buttons will | never match this, regardless of the value of the attribute), as well | as elements defined by this specification that are not form controls | (namely form, label, datalist, option, optgroup, and fieldset | elements). First of all, he shouldn't mention elements...that are not form controls in the first place, because he's saying that they can be specifically selected by :read-only when the whole point should have been to eliminate anything that might conflict with CSS3-UI, and obviously if we change CSS3-UI to use the XForms definition of :read-only, this will conflict. Second, why would I need :read-only on things like label, option and optgroup? Outside an HTML editor, how would I even edit something like that?!? At the very least, Ian should have done this: | Matches form control elements that have the readonly attribute set, | and to which the readonly attribute applies (thus radio buttons will | never match this, regardless of the value of the attribute), as well | as other elements defined by this specification that are defined as | read-only under the CSS3 Basic User Interface Module. I don't think WF2 should contain ANYTHING that is specifically in violation of the original XForms definition of :read-only and :read-write. Outside of form controls, the only time an element isn't read-only is when it's within an element that has |contentEditable| set Or when the whole document is in an editor, as opposed to a browser. What's the use case for editor-specific presentation (especially when there's no such media as editor, so far as I know)? So :read-only is never useful in the context of HTML 4.01 + Web Forms 2.0. Again, my concern is with WF2 specifying things that affect behavior outside of its context. My concern is that CSS3-UI has expanded the definitions of :read-only and :read-write to the point where they serve no useful purpose. If your user agent is both a browser and an editor simultaneously, and you can actually edit even input readonly elements, then even a read-only input in markup is potentially :read-write. Does input readonly match :read-only if it's inside a |contenteditable| element? Personally, I don't thinking we should be styling around the editing capabilities of user agents unless that editability is defined as part of HTML. Editors can apply their own styling for editing, so I see no point in giving authors the ability to change the way elements look in an editor. It would only serve to confuse people using the tool. I agree that how :read-only behaves with respect to elements in a |contenteditable
Re: [whatwg] [WF2] Readonly and default pseudoclass matching
Ian Hickson wrote: On Sun, 31 Jul 2005, Matthew Raymond wrote: Ian has sadly chosen to change the text to this: | Matches form control elements that have the readonly attribute set, | and to which the readonly attribute applies (thus radio buttons will | never match this, regardless of the value of the attribute), as well | as elements defined by this specification that are not form controls | (namely form, label, datalist, option, optgroup, and fieldset | elements). First of all, he shouldn't mention elements...that are not form controls in the first place, because he's saying that they can be specifically selected by :read-only when the whole point should have been to eliminate anything that might conflict with CSS3-UI, and obviously if we change CSS3-UI to use the XForms definition of :read-only, this will conflict. Note that the text above was reviewed by the editor of the CSS3 UI spec and given the all-clear. Of course he gave it the all clear. He's the one who wrote the disputed portion of the spec in the first place. CSS3 UI is pretty clear about the fact that pretty much all elements match either :read-only or :read-write, for example is a document is loaded in an editor (say, Amaya), all elements become :read-write. And if it's changed later, say in a CSS3-UI Revision 1, you'll have to change the language in WF2 to follow suit, because WF2 deliberately reiterates parts of the current CSS3-UI. Second, why would I need :read-only on things like label, option and optgroup? Outside an HTML editor, how would I even edit something like that?!? The HTML editor is a major use case, as is contentEditable. No, the latter has a use case, one that I have suggested an alternative to (:editable). No one has properly explained why the former is a use case, because you'd potentially want consistent styling with regard to editor-specific presentation. I don't think WF2 should contain ANYTHING that is specifically in violation of the original XForms definition of :read-only and :read-write. XForms is irrelevant here. Its section is non-normative, and its working group has no authority over CSS (at best it can do what we're doing, namely, defining how CSS3 UI maps to XForms). CSS3 UI is what matters, not XForms. (I'm a member of the CSS working group and we worked closely with the XForms working group as far as CSS3 UI goes, for what it's worth.) What's the use case for editor-specific presentation (especially when there's no such media as editor, so far as I know)? N|vu, e.g. (Why would it be a media? The media is screen, typically.) Some kind of pseudo-class would probably be better, since the editor could potentially be using media. That doesn't explain why :read-only and :read-write should be used for editor-specific presentation. My concern is that CSS3-UI has expanded the definitions of :read-only and :read-write to the point where they serve no useful purpose. I recommend sending your comments to www-style. As far as WHATWG goes, we have to take CSS3 UI as gospel and work from there. Even so, you could simply refer generally to CSS specifications without restating their content. By restating content, you make the spec potentially incompatible with future revisions of the CSS3-UI spec. Actually, they're mutually exclusive in markup. When are you ever going to have input readonly disabled? When the control which would otherwise be readonly is irrelevant. It could be readonly because it's being used much like an output field (but one that will submit). It would be disabled when its value is not relevant, e.g. because that part of the form is not being used. In a script-free scenario, you might as well be using span. In a scenario with script, when would you disable the input readonly element specifically and in markup rather than disabling a parent fieldset? Considering the fact that greater than 90% of browser users don't even have a browser that can edit otherwise static content Just visit javascript:document.designMode=true to make any document editable in IE. (Untested, I might have the wrong syntax.) :editable.
Re: [whatwg] [WF2] Readonly and default pseudoclass matching
Ian Hickson wrote: On Sun, 31 Jul 2005, Matthew Raymond wrote: Ian has sadly chosen to change the text to this: | Matches form control elements that have the readonly attribute set, | and to which the readonly attribute applies (thus radio buttons will | never match this, regardless of the value of the attribute), as well | as elements defined by this specification that are not form controls | (namely form, label, datalist, option, optgroup, and fieldset | elements). First of all, he shouldn't mention elements...that are not form controls in the first place, because he's saying that they can be specifically selected by :read-only when the whole point should have been to eliminate anything that might conflict with CSS3-UI, and obviously if we change CSS3-UI to use the XForms definition of :read-only, this will conflict. Note that the text above was reviewed by the editor of the CSS3 UI spec and given the all-clear. Of course he gave it the all clear. He's the one who wrote the disputed portion of the spec in the first place. Which disupted section of which spec? For CSS: http://www.w3.org/TR/2004/CR-css3-ui-20040511/#pseudo-ro-rw For WF2: http://whatwg.org/specs/web-forms/current-work/#relation If there is a dispute about a CSS spec, this is the wrong forum. Please move such discussions to www-style, where the discussions have a greater-than-zero chance of actually causing the CSS specs to change. :-) True, which is why I moved part of this discussion to www-style already. However, what I'm trying to address is your recent revision of WF2. If the disputed section is the one I wrote (i.e. the one quoted above) then no, he didn't; I wrote it. I never said he wrote it. You altered WF2 to make it repeat aspects of what he wrote (CSS3-UI). Obviously the person who wrote the sections of the CSS3-UI spec you're drawing from is going to agree with corrections that reinforce his own content. I recommend sending your comments to www-style. As far as WHATWG goes, we have to take CSS3 UI as gospel and work from there. Even so, you could simply refer generally to CSS specifications without restating their content. By restating content, you make the spec potentially incompatible with future revisions of the CSS3-UI spec. The problem is that CSS3 UI is not clear enough to lead to interoperable specifications in the context of WF2. Thus, it is my responsibility, as editor of WF2, to clarify how the specs interact. As editor, I also take on the responsibility of tracking future revisions of CSS3UI to ensure they do not break us, and that WF2 is updated to track CSS3UI changes. (The same applies to all WF2's dependencies.) What was wrong with the revision I suggested?... | Matches form control elements that have the readonly attribute set, | and to which the readonly attribute applies (thus radio buttons will | never match this, regardless of the value of the attribute), as well | as other elements defined by this specification that are defined as | read-only under the CSS3 Basic User Interface Module. There's no reason to rewrite parts of WF2 if it's written to avoid such problems in the first place. In a scenario with script, when would you disable the input readonly element specifically and in markup rather than disabling a parent fieldset? There might not be a parent fieldset. In any case, what's the difference? So, when am I going to need to disable a single read-only control independently of other controls? Not seeing a use case here.
Re: [whatwg] [wf2] disabled default submit button
[EMAIL PROTECTED] wrote: Quoting Matthew Raymond [EMAIL PROTECTED]: Should be as easy as inserting the word non-disabled somewhere... That would make both Firefox and Opera non-conforming. True, but then why should the default be set to a disabled button? Sad to say, the IE behavior makes more sense.
Re: [whatwg] [WF2] Readonly and default pseudoclass matching
Boris Zbarsky wrote:
Matthew Raymond wrote:
Take a look at the following URL:
http://www.w3.org/TR/2003/REC-xforms-20031014/sliceF.html#id2644859
That has no bearing on how :read-only is to be applied outside the context of
the XForms namespace. Like to HTML, say. Which brings us back to WF2, which
is
working with HTML...
WF2 stands for Web Forms 2. Why would it even define :read-only
for non-forms elements? Now that I'm thinking about it, if you want
:read-only to apply to non-control elements, you should extend the
selection of the pseudo-element in WA1, since such a suggestion has
nothing to do with web forms.
So, clearly, when :read-only was first introduced for XForms, it was
meant to be used only with form controls that are not only set to
read-only, but are actually capable of being set to read-only in markup.
Which makes some sense in the context of XForms, where form controls are what
you care about styling. Outside of that context, that seems like a very
unreasonable restriction.
Outside of form controls, the only time an element isn't read-only is
when it's within an element that has |contentEditable| set, which will
probably be defined in WA1, not WF2. So :read-only is never useful in
the context of HTML 4.01 + Web Forms 2.0.
I agree that how :read-only behaves with respect to elements in a
|contenteditable| container needs to be defines. However, it doesn't
need to be defined in WF2.
Thought for WA1: Allow :read-only to work for elements with a
|contenteditable| attribute defined but the .contentEditable property
set to false. It could work like this...
HTML:
| div id=x303 contenteditablepThe quick red fox.../p/div
CSS:
| div p { /* Styling for a standard paragraph in a div. */ }
|
| #x303:read-write p {
| /* Styling for an actively editable paragraph. */
| }
|
| #x303:read-only p {
| /* Styling for a potentially editable read-only paragraph. */
| }
Note that the actual p child element cannot be selected directly
using :read-only.
The XForms spec clearly states :read-only selects a form control, so
if :read-only is a way to style elements which are in the respective
states as defined by XForms, then it can't apply to a non-control element.
Sure it can, if the non-control element is not in the XForms namespace (if
nothing else, you can then just style XForms-namespace content that matches
:read-only, if desired).
Your argument doesn't make any sense. XForms defines pseudo-classes
for use with XForms elements, which are by definition all form elements.
Why expand pseudo-classes obviously intended for form elements to
non-form elements?
WF2 is claiming to be doing exactly such clarification, if you note.
WF2 can suggest how styling should be handled, as XForms did, but it
needs to ultimately be defined by CSS.
Actually, no. CSS defers to document languages on a number of issues; HTML5
and
specifically the Web Forms 2 part of it is such a language. XForms is
another
language. CSS just defines that a :read-only psuedo-class exists and leaves
it
up to the document language to define what is matched by it. XForms has such
a
definition.
Then it really doesn't matter what CSS3-UI says? In that case, we can
just leave the spec unchanged, as it clearly defines what :read-only
applies to, and doesn't prevent us from expanding how we can use it later.
So does Web Forms 2, but the Web Forms 2 definition seems
inadequate to me in the context of HTML5. If Web Forms 2 were somehow
separate
from HTML5 that might be OK, but it's not.
I see nothing inadequate about the current definition, nor do I see
any useful purpose that is served by changing it.
The width of the checkbox is 100 pixels. You should have used the
:disabled pseudo-class from CSS3-UI:
I realize :disabled would match there. The question is why :read-only should
not match -- the checkbox is readonly in this case; the user can't change its
value.
No, the checkbox is disabled. Read-only controls are typically
inaccessible for the life of the application. Disabled controls may be
enabled, and therefore must have styling to indicate that the contents
are only temporarily inaccessible. Also, read-only controls are more
likely to have their values changed by the program (for instance, if
it's used for a subtotal), where as disabled controls usually have their
values fixed while they are disabled.
Again, this comes back to the basic question of what does :read-only
select?
Is it read-only elements or form controls that have a readonly attribute
in
the DTD and have it set?
Clearly, if you're looking at markup and want to know what :read-only
selects, and you see an element of the form [element] readonly, you'd
expect that to be selected. By contrast, you don't think of a simple
paragraph in terms of read-write access, so you may not think of that
being selected by :read-only, especially when dealing with
pseudo
Re: [whatwg] [wf2] disabled default submit button
Anne van Kesteren wrote: # !DOCTYPE html # form method=get # pinput name=t1 # pinput type=submit name=s1 disabled=disabled # pinput name=t2 # pinput type=submit name=s2 # /form (1) When t1 is focused the default submit button in IE is s2 and in Opera and Firefox it is s1 but disabled so it does not work. (2) When t2 is focused the default submit button in IE, Opera and Firefox is s2. In both situations all non disabled form controls are submitted. Yeah, button s1 should never be submitted. Button s2 should be the default button. I think a change has to be made to the specification as it does not reflect reality, although reality can be quite ugly. Should be as easy as inserting the word non-disabled somewhere...
Re: [whatwg] [WF2] Readonly and default pseudoclass matching
Boris Zbarsky wrote:
Matthew Raymond wrote:
Seeing as |readonly| is only defined as an attribute for textarea,
input type=text and input type=passwd in HTML 4.01, I would
consider WF2 as expanding the use of |readonly|, not restricting it.
Why does :read-only have anything to do with the readonly attribute?
See below.
In the section where :read-only is introduced, it has the following
paragraph:
| Specifically, these new states (except for :default) are provided as a
| way to style elements which are in the respective states as defined by
| XForms [XFORMS10].
Sure. But later on the actual definition of :read-only makes it clear that
it's
not limited to just XForms:
An element whose contents are not user-alterable is :read-only. However,
elements whose contents are user-alterable (such as text input fields) are
considered to be in a :read-write state. In typical documents, most
elements
are :read-only. However it may be possible (e.g. in the context of an
editor)
for any element to become :read-write.
Please note last sentence.
Take a look at the following URL:
http://www.w3.org/TR/2003/REC-xforms-20031014/sliceF.html#id2644859
It describes how XForms controls can be styled. Note the section about
read-only and read-write:
| Selects any form control bound to a node with the model item property
| readonly evaluating to true or false (respectively).
So, clearly, when :read-only was first introduced for XForms, it was
meant to be used only with form controls that are not only set to
read-only, but are actually capable of being set to read-only in markup.
What I'm seeing in CSS3-UI is contradictory with respect to the
XForms spec. True, that part of the XForms spec is normative, but it's
clear reference by the section I quoted above, so CSS3-UI is clearly
self-contradictory.
Therefore, unless XForms defines these states for elements other than
form controls, :read-only should not be used for elements like
fieldset that don't have a |readonly| attribute.
I'm not seeing what gave you that idea.
The XForms spec clearly states :read-only selects a form control, so
if :read-only is a way to style elements which are in the respective
states as defined by XForms, then it can't apply to a non-control element.
I do agree, though,
the there needs to be clarification in the CSS3-UI spec, but I'm not
sure such clarification belongs in WF2.
WF2 is claiming to be doing exactly such clarification, if you note.
WF2 can suggest how styling should be handled, as XForms did, but it
needs to ultimately be defined by CSS.
That's just it. It's invalid in WF2 to use |readonly| on radio
buttons and checkboxes.
Excuse me?
html
style
input[type=checkbox] { width: 100px; }
input[type=checkbox]:read-only { width: 200px; }
/style
input type=checkbox disabled=disabled
/html
Now, what's invalid here? What's the width of the checkbox?
The width of the checkbox is 100 pixels. You should have used the
:disabled pseudo-class from CSS3-UI:
| input[type=checkbox]:disabled { width: 200px; }
You seem to be confusing the readonly attribute and the :read-only CSS
pseudo-class...
Not at all. See the following URLs:
http://whatwg.org/specs/web-forms/current-work/#readonly
http://www.w3.org/TR/html4/interact/forms.html#adef-readonly
Re: [whatwg] [html5] onbeforeprint/onafterprint (was window.print() undefined)
Dean Edwards wrote: Matthew Raymond wrote: 1) The feature can be abused. All features can be abused. Yes, but some more than others. 2) It alters the standard behavior of the browser. No it doesn't. Uh, yes it does. Perhaps the problem is that CSS clouds the issue. Since CSS is not required for HTML compliance, let's look at how a non-CSS browser would be effected by onbeforeprint/onafterprint. Without these events, the printout of the page would always match what you have on screen (barring the user agent deliberately making it look different). Therefore, while using this browser, if I see something that says the following... | Matthew is a great guy. ...and I print it, I would expect the printer to print out this: | Matthew is a great guy. By contrast, I would not expect the printer to give me the following: | Matthew is a complete luzor!!! That's what these events enable, and that's a fundamental alteration of the expected behavior of a user agent's printing function. 3) It can be easily disabled with a modified open source browser or browser extension. So? So it's useless for keeping people from printing stuff without paying if the people in question really want to print something. Also, you could probably also use copying and pasting to a word processor to do a complete end run around these events. 4) It's use cases are partially covered by CSS. ditto. 5) There are existing workarounds. ditto. So we should ignore both cost and benefit when implementing new markup??? 6) An alternative has been proposed that has less potential for abuse, is more powerful, and doesn't change basic browser functionality. What alternative? I'm covering that in a separate email to Anne right now, but I've mentioned it several times before.
Re: [whatwg] [html5] onbeforeprint/onafterprint (was window.print() undefined)
Dean Edwards wrote:
Matthew Raymond wrote:
Dean Edwards wrote:
Matthew Raymond wrote:
| if (documentchanged) {
| printClone = document.clone();
| prepareForPrinting(printClone);
| }
|
| printClone.print();
This seems less practical than print events.
I don't see how:
| OnBeforePrintEventFunction() {
| prepareForPrinting(document);
| }
|
| OnAfterPrintEventFunction() {
| restoreForScreen(document);
| }
I mean less practical in terms of memory management. Cloning a document
every time you alter it would likely lead to terrible performance.
Granted, the JavaScript looks slightly neater.
Well, we could do something like this:
| document.DOMPushState();
| prepareForPrinting(document);
| window.print();
| document.DOMPopState();
My concern was that there would be a visual change on the screen just
before printing. You could just have it to where redraw is blocked by
some mechanism, but what happens if the script crashes and the redraw is
never restored?
Actually, that above example is effectively this:
| prepareForPrinting(document);
| window.print();
| restoreForScreen(document);
S... Why did we need those events again? (Well, I can think of
one single reason: so you don't have a print button to hide in non-CSS
browsers. But wait, is that actually a problem??? This is where my
inexperience with Javascript rears its ugly head.)
Still, we need a way to easily print from an altered DOM without
destroying the original DOM state. Cloning seems the safest, most
problem free way, but as you say, it initially doubles the memory.
Quick Thought: Is there even a real use case for people printing from
a non-CSS user agent? If a user agent is sophisticated enough to print,
wouldn't it be sophisticated enough to use CSS for the print media?
Could someone, for instance, point out a phone that prints out
non-styled HTML to a printer?
Re: [whatwg] [html5] window.print() undefined
Dean Edwards wrote: OK, we don't switch media. But when I press print or invoke the print method, a copy of the DOM is sent to the printer. If I have altered the DOM by adding elements or by changing the style property then I would like to be able to undo those changes before my DOM goes to the printer. It is not good enough to say that I should start messing about with classes and so forth or that it is bad practice to amend the style property directly. So long as I can do these things I want a way to undo them before my DOM is sent to a print device. I know this isn't how you meant it, but this all seems a bit user hostile. The user sees something on the screen he/she wants to print, but an event is called at the last minute that changes the content to something else before the user can print. So if I select the part of the page you want to undo and tried to print the selection, I'd get a blank page? And in theory, the entire page could be hidden. Sounds like print-specific DRM to me. Perhaps what you really want is a media-specific way of setting styling properties: | element.style.media(print).display = block;
Re: [whatwg] [html5] window.print() undefined
Sjoerd Visscher wrote: Matthew Raymond wrote: I know this isn't how you meant it, but this all seems a bit user hostile. The user sees something on the screen he/she wants to print, but an event is called at the last minute that changes the content to something else before the user can print. So if I select the part of the page you want to undo and tried to print the selection, I'd get a blank page? And in theory, the entire page could be hidden. Sounds like print-specific DRM to me. You can do that with css anyway, what is your point? That CSS can be overridden by the user stylesheet? Every browser feature adds opportunities to both help and annoy the user, but please let is be up to [the] web developer to act responsible with the features he has available. Who wants to annoy the customer anyway? Businesses annoy customers all the time, but that's beside the point. If all HTML content is semantic rather than presentational, what is the purpose of not displaying it in a specific media? We're not talking about media-specific presentation (since CSS+XBL handles that nicely). We're talking about media-specific content. The only reason I can think of for such control is if you're using the web app like a word processor or something and you want to print the document but not the UI. In that situation, it may be better to simply allow the web developer to copy the document contents into a separate document object, then manipulate and print the content from that document separately. This allows the same effect as the before and after print events without tampering with the browser's normal print mechanism. You just clone the document, modify the clone at will, print it and destroy it. The web app should never hijack the behavior of a common browser function.
Re: [whatwg] [html5] window.print() undefined
Jim Ley wrote: This is flawed though, as it requires all the content to be in the page, including media-specific content. CSS cannot remove content, CSS is optional, consider: This page span id=viewedviewed/spanspan id=printedprinted/span on ... This is a contrived example of how people want web-applications to have media specific content - printed media particularly, although it would also apply to web applications deployed over interactive voice systems, but it shows how relying on optional methods to change content is simply flawed. I understand what you're saying, but I don't agree that events related to UA printing of the web document is the answer. For instance, such events could be combined with AJAX to force people into a pay-to-print scenario. There's just to much potential there for the web developer to control the user, and even if you considered that a valid thing to do, the user could simply create a Firefox fork or extension to circumvent it. There are two far better options. The first option is the one Mapquest and other sites use: provide a link to a printable version of the page. It's not ideal for all cases, but it probably satisfies most of the use cases where CSS isn't an option. The second is to allow the document object to be cloned, to allow operations to be performed on the clone, and then to allow printing from the clone. This allows specialized printing without tampering with the user's ability to do basic page printing. In my opinion, we should just have people do the former until we have interfaces for the latter.
Re: [whatwg] Suggesting a 'transpose' Attribute for Tables
Christoph Päper wrote:
both table models, HTML and CSS, are row-centric, i.e. sequential data
is shown horizontally. Sometimes the opposite is desired. Therefore I
wonder if it was feasible to add a boolean 'transpose' attribute to
the 'table' element type? With it set, a table would be rendered
column-progressive despite 'tr' meaning table row; it includes the
row-groups ('thead', 'tfoot' and 'tbody'). Actually I am not sure
whether it is not too presentational and thus would better be done in CSS.
Wouldn't this be possible using display in CSS instead?
Obviously, it would be possible for the UA to offer a transpose
feature. Not sure if we need it for HTML. Is there even a use case for this?
Re: [whatwg] WA1: rev attribute
fantasai wrote: The 'rev' attribute from prior versions of HTML is missing in WA1, and I think it deserves not to be left out. I don't. It's almost entirely useless, and no one really uses it anyways. Most common link types out there are used with 'rel', but some 'rev' values can also be useful. Here are some use cases: - rev=footnote for a link back from the footnote or endnote to the source anchor in the main text - rev=help for a link to the part of the site that the help text is about This is largely useless, as you are unlikely to start at a help/footnote document and go to the document for which the help document was written. The most common situation is that you clicked the help/footnote like from the parent document, and therefore the relationship is already established from the parent document. - rev=author on a personal site or resume for links to documents s/he has written Here, you're using |rev| to replace missing metadata in the target document. What happens when meta name=Author is defined in the target documents? Does |rev| override? What would a UA do with the information anyway? If there's a link, wouldn't there be text stating that the creator of the personal site created the document the link is to? See also http://www.eastgate.com/HypertextNow/archives/Trigg.html for a direction link types could go in which 'rev' would be useful. Well, I scanned over it, and I noticed one good point. People often don't bother putting in relationship types for links. Therefore, |rev| could establish what the relationship is when you reach the target document. The problem is that the argument is mostly self-defeating. If people fail to use |rel|, how is a reverse version of that same attribute going to be used with any frequency. At least with |rel|, you could harvest hyperlinks and put them into a link toolbar. With |rev|, you're describing the relationship type of the current document. Therefore, I really don't see what user agents are supposed to do with |rev| and how they can create a useful interface that can exploit this attribute. Many of the link types suggested there would be easier to use with rev for the reverse link than with a separate keyword that means the inverse relationship. Example: rev=refutation to link to the article one is refuting Counterexample: | meta name=refuting content= | Intelligent Design; | http://hemadeyou.org | True, from a pure language standpoint, |rev| is more convenient. However, if the author makes the hyperlink text Click here!, and the link is broken, what does the user agent have left to work with? The same kind of abuse is not likely to happen with meta.
Re: [whatwg] WA1: rev attribute
[EMAIL PROTECTED] wrote: The user interface of rel and rev can be exactly the same, only rev under the heading of reverse. AFAIK there is no difference between a href=1.html rel=prev and a href=1.html rev=next So, functionally, you're just breaking a link toolbar into two categories: forward and reverse. What's the use case for this? Surely a Previous button in your links toolbar is better than Reverse-Next from a UI perspective. Or are you suggesting that the UA should determine the reverse of the relationship and present a button for it? That's really bad for things that don't necessarily have inverses: |rev=top| - bottom? |rev=first| - last? |rev=top| - bottom? |rev=ToC| - ?? Also note that refutation is a bad example, as it would only ever be used in |rev|. Does anyone ever link to a refutation of their article from the article itself??? So what we're seeing is that |rev| encourages us to define relationship types specifically for |rev| that are useless for |rel|. Another thing is that |rev| is largely self-serving: | a href=http://whatwg.org; rev=supreme-master-guru By it's nature, |rev| defines how the universe relates to you. Thus, how can you help but put yourself at the center of the universe?
Re: [whatwg] [html5] window.print() undefined
Jim Ley wrote: On 7/18/05, Ian Hickson [EMAIL PROTECTED] wrote: Why would you suspend a timer? (And why would the UA not suspend the timers itself?) You're saying that when a user print's an HTML5 user agent MUST stop all setTimeout counters, I don't see that in the spec, nor why it would be an expectation of a scripter. So wait, we need to add new events because user agent vendors may be too stupid to solve print-related problems on their own? I'd rather not have events just to fix random user agent problems. The common use of onbeforeprint/onafterprint is to add content to a document that is only relevant to printed media, this is something that cannot be done with CSS, since CSS is optional, so if we just hide content with CSS, we're stuck with the situation that users without CSS or with an appropriate user stylesheet get it and get confused. What about the browsers that don't support Javascript, or have it turned off? Plus, what semantic content are you going to have that shouldn't display in all media types? I suspect that if you have to add or remove content for CSS-free user agents, you're probably using a lot of presentational HTML markup. Of course for showing temporarily hidden stuff with script, as has been mentioned, there's no problem doing it with CSS. Correct. Personally, I think using inline styles via the DOM should be discouraged in most if not all cases.
Re: [whatwg] [WF2] Web Forms 2.0: Repetition and type ID
fantasai wrote: I'd like to suggest that ID attributes use a different syntax than [] to mark repetition placeholders, one that fits with the XML restrictions on IDs. The current syntax makes it impossible to define ID attributes as type ID in any of the three major XML validation schemas, which affects both the usefulness of authoring tools that rely on IDness (e.g. for navigational tags or for catching duplication and referential errors) and the integrity of other specs (such as the CSS 2.1 specification) that rely on such definitions. I don't care what the syntax is (I suggest :-replaceable-: for lack of anything better), and it doesn't have to apply to other attributes where [replaceable] is more natural. Couldn't we just solve this with an attribute called templateid that would be used in place of the |id| attribute for templates. We could then use |id| for backwards compatibility. | html xmlns=http://www.w3.org/1999/xhtml; | head | titleSolar System/title | /head | body | form |h1 Solar system /h1 |p label System Name: input name=name/ /label /p |h2 Planets /h2 |ol | li repeat=template repeat-start=0 templateid=planets | label | Name: input name=planet[planets].name required=required/ | /label | h3 Moons /h3 | ul | li repeat=template repeat-start=0 |templateid=planet[planets].moons |input name=planet[planets].moon[planet[planets].moons]/ |button type=removeDelete Moon/button/ | /li | /ul | pbutton type=add template=planet[planets].moons | Add Moon | /button/p | pbutton type=removeDelete Planet/button/p | /li |/ol |pbutton type=add template=planetsAdd Planet/button/p |pbutton type=submitSubmit/button/p | /form | /body | /html
Re: [whatwg] [WF2] Web Forms 2.0: Repetition and type ID
Just had a thought: rename this to repeat-id so people don't
confuse the repetition system with a templating system.
Ian Hickson wrote:
On Sat, 2 Jul 2005, Matthew Raymond wrote:
Couldn't we just solve this with an attribute called templateid that
would be used in place of the |id| attribute for templates. We could
then use |id| for backwards compatibility.
I don't understand how that would help. The problem is not with the
templateid attribute, it's with any ID attribute. For example:
input id=field[x] ...
...if you want to give the fields a unique ID in each repetition block.
My knowledge of the subject is limited, but it's my understanding
that the use of [ and ] is a source of difficulty due to XML schemas
and the limitations of software tools. However, there are no such
limitations on a simple string attribute which can be used to GENERATE a
unique |id|.
Now, consider CSS. If you have and |id| that contains
planet[planets].moons, the following doesn't work in Firefox, Opera or
IE6:
| #planet[planets].moons { /* CSS properties here. */ }
Nor does this:
| #planet[planets] { /* CSS properties here. */ }
However, this does:
| [repeat-id=planet[planets].moons] { /* CSS properties here. */ }
Well, IE6 doesn't recognize the last example. (No real surprise
there.) It needs an |id|. With |repeat-id|, you just specify a regular
|id| attribute on the repeating element.
(Me thinks the planets example may be flawed regarding the periods...)
In theory, you could have |repeat-id| be equal to |id| in cases
where |repeat-id| is not specified. Personally, it makes more semantic
sense to me to have |repeat-id| required, because it makes it clear that
the |id| is used in the repetition process.
(Also, multiple ID attributes per element would also be a problem in most
schema languages, and square brackets are a problem in any ID attribute,
not just id.)
It's not an attribute of type ID. That's the whole point. The
repetition system converts it into an |id| when it generates a new block.
Re: [whatwg] showModalDialog
Hallvord Reiar Michaelsen Steen wrote: On 1 Jul 2005 at 13:27, Karl Pongratz wrote: click edit in my fancy address book application, a modal window pops up, I want to go to the tab where my E-mail lives to copy the address I wanted to put in my address book and ... ouch, can't get to the E-mail because I use an integrated browser/mail client application and the modal dialog blocks access to all the tabs. If you want to copy an email address you will have a problem with any web app I think, traditional and Ajax based once. Perhaps you misunderstood that? I as a user expect to be able to switch between tabs to copy and paste information between different pages. A modal dialog breaks that. Yeah, and I can't really see a way around that. If you can change the z-order so that the parent window is above the child, you've already violated one standard UI convention regarding modal windows. So even if the modal nature of the dialog only applied to the HTML viewing area, back/next buttons and the address bar (and bookmarks, et cetera), which violates UI conventions right there, you'd still have the z-order issues. So the simplest way to go is to have chromeless windows instead of modal ones. However, in the scenario where chromeless windows are permitted, we still have to deal with tricks involving simulated chrome designed to trick the user and other stuff. We definitely need to decide how to handle chromeless windows. If you want to do that in a nice way you may need to use at least chromeless windows, yet you could use modal windows from the already opened chromeless windows, then you can access your main page even if a modal window is active. I see, you expect your app to live in a window of its own and not in a tab. Only to get rid of browser UI like back button and address bar? LOL, I'm your web app's user from hell, I routinely duplicate windows to go back in history and see what I wrote and if I use IE and you open a poup without address bar I view properties and copy the address just to get my normal UI back. I know it is hard to keep up with such behaviour from the backend, but I expect your app to manage. Thank you. It's important to point out that users may not be using chrome by accident. This is what I meant by user hostile in previous messages. Modal dialogs block access to the UI that the user needs to control the browser. The whole point is to limit user control so that your application doesn't need to be as robust and doesn't have to deal with multiple input scenarios. If the user MUST do something a specific way, then you don't have to write code for any other way the user might try to accomplish the task. It's shifting part of the cost of development from the developer to the user. Is it possible to keep the two discussions chromeless windows and modal dialogs separate, please? If you're talking about modal dialogs, chromeless windows have to come up because modal dialogs must be chromeless. However, the modal conversation can be put on hold until we figure out whether chromeless windows are acceptable in one form or another.
Re: [whatwg] Re: modal and modeless windows
Karl Pongratz wrote: James Graham wrote: Karl Pongratz wrote: Matthew Raymond wrote: Every indication is that chromeless windows are on their way out. I would be very sad if that would happen. Its currently the only way to keep forms out of history and to unlock them from the back/next button. So I would suggest to keep them and improve them rather than removing them. Well if you can think of an easy way to improve them so that they a) obviously belong to the browser and b) clearly display the full location then I'm sure UA vendors will be happy to hear from you. Otherwise, the internet being the way it is, chromeless windows, on the public internet at least, have a short life expectancy. Yep, I would be very happy with this approach, to lock chromeless windows to the user agent and to always show the full location, and that you can't connect to another domain than of the domain from where you opened the window. This modification shouldn't be that difficult to implement for user agent vendors, I think... and hope. As far as I remember the domain restriction already exists. Did it occur to anyone that this is all hostile to the user? You prevent the user from accessing controls for browser (buttons, menus, et cetera). You prevent the user from going to another domain. You block their access to an underlying window. This all smacks of let's control the users, because the users are stupid. I have no objection to avoid them if they are not really required. Though what doing in the rare cases where you can't avoid them, I guess Apple applications are still using modal windows in the one or other case, and they will remain for another decade or two. Or is it different? It seems to me that two different issues have been conflated here: modal windows (those which prevent their parent window from being focused) and chromeless/navigationless windows. Whilst there are a very few occasions in which I can see modal windows being useful I can also imagine that they would be abused for all sorts of nasty things (even more instrusive adverts, for example). The case where you require modal windows may be rare, yet they are extremely useful in those cases, I remember they are on the web applications wish list at Joel on software as well, http://www.joelonsoftware.com/oldnews/pages/June2004.html , section Thursday, June 17, 2004.** Yeah, but he really doesn't way why. I was hoping he'd have a use case in there somewhere... Yep, I am afraid that modal windows would be abused, as many other things, though I consider some content you find on the web much more harmful than modal windows could ever be, yet you allow authors to publish content on the web :-). Thinking more about it, in my case I would require the modal windows on already opened chromeless windows, that could be a solution, limiting the use of modal windows to already opened chromeless windows, so that you can't open a modal window right away from a regular web browser window, that would make it much more difficult to abuse them. That is something I would be happy with and may cover most use cases where modal windows are required. Congratulations. You just reinvented xul:dialog. :) Seriously, though, why not just standardize a subset of XUL (sXUL) and use a compound document (XHTML + sXUL). We could make sXUL the standard for browser extensions while we're at it.
Re: [whatwg] modal and modeless windows
Karl Pongratz wrote: Let's take the subscription page in case that we would have a modal window. You would still browse to the subscription page, though it wouldn't have any form field on it, instead there is a link Click here to subscribe, clicking on it opens a modal window (smaller than the main window), which contains the form fields for the subscription. Fill in the form, submit it, show some Thank you for your subscription, that's it, then close the window manually. You may not want to do that for very simple forms like a subscription page, but it becomes very handy for complex forms where you use a lot of DHTML, AJAX, Xforms or whatsoever. As far as I know, AJAX applications break your web browser history, though if you do the complex AJAX part, let's say a complex Wizard, inside a modal window then it wont break you web browser history, and you wont have pages in your web browser history which shouldn't be there anyway. If you have AJAX, why not submit form data via XMLHttpRequest rather than changing the current URL? That way, there is no back button within the context of navigating the application.
Re: [whatwg] modal and modeless windows
Karl Pongratz wrote: Well, if you have a Wizard with 6 steps done by AJAX, how do you explain to the user that he/she can't anymore use the web browser back/next button to navigate through the Wizard? Imagine you are at Wizard step 6, have filled in a ton of form fields and accidentally click the web browser back button, it will lead you somewhere, maybe to a resource you have visited before the Wizard resource. Does that sound as a logical browsing model which a user will ever understand? Actually, the logical thing would be to have each step as a separate AJAX-based web page, where changes to fields are reported back to the server. The server then keeps track of the values of the fields for each step and can repopulate the fields when you use the forward and back buttons. No modal windows necessary. Beside that, how many desktop applications do you know which don't use modal and modeless windows? In most cases, if you show me an application with a modal window, I'll show you an application that needs to do away with a modal window. The use cases for applications that truly need modal windows probably overlaps the use cases for XULRunner-base applications quite nicely. I know many without a back/next button, but none without modal window support comes into my mind. Considering that back/next buttons were invented later, that proves little. For instance, any kind of preference or settings dialogs you can think of could be put in a collapsible sidebar. I personally worked on a project where they had forward and back buttons for three different levels. Wizards are a perfect example of back/next as well, and there are plenty of those. Is the web browser damned to limit it to back/next only? Will the only alternative be Java Webstart, Microsofts XAML or Flash to get a desktop like user interaction model? I can't think of much you can't do with these technologies that you can't do with existing web app technology. It's simply faster or has more native features. For instance, menus are easily simulated by DHTML-based web apps. Similarly, you could easily simulate modal windows by using a few div elements and disabling various controls. Considering modal-anything is generally considered bad UI, I don't think we should encourage it, especially when it's so incompatible with current browser usage.
Re: [whatwg] Re: modal and modeless windows
Karl Pongratz wrote: I could envision that as follows, lets take the address book of Microsoft Outlook, the desktop application, as an example. You have a page (resource) my_addresses.html, a simple document that shows you all your addresses without any form fields. If you want to edit an address you click on it, which will open a modal window, this modal window should then contain the xforms document to edit the address, with a Save and Close and Cancel button. Cancel will close the modal window, no other action is taken. Save and Close will save the form data, closes the modal window and it will update the changes in the underlying my_addresses.html document, i.e. by reloading it. Where do you need modal windows in this model? Someone clicks on the edit link to bring up an address editing page in a new window. You edit, then click save or cancel, which closes the window. AJAX and server-sent DOM events update the original window when you save. If the address is deleted or altered, server-sent DOM events can update the editing window to act accordingly. (In the event of a deletion, for instance, the editing window could change to a simple page saying This address has been deleted.) Since the dialog is not modal, you can edit multiple addresses at the same time, and you can even do so while the buddy you're sharing the address book with is editing it. As far as links go, the newly created address editing windows don't have a previous window because they were just spawned, and if they don't need links to load inside the window, then don't put any or have them spawn new windows. So I ask you, for this example, where is the benefit of modal windows?
Re: [whatwg] Re: modal and modeless windows
Karl Pongratz wrote: Matthew Raymond wrote: So I ask you, for this example, where is the benefit of modal windows? I am using the current approach you describe, and as long as you have only a single additional window (the edit form) open it wouldn't be a problem, except if you want the user to explicitly complete a task, then modal would be required. I'm going to be lazy and ask you to provide the use case, since you're the one claiming one exists in the first place. In case of the addresses modal may not be required, it depends if you want to allow the user to delete a contact while the same contact is open in the edit form. Simple way around that. Put the delete button in the editing window. It probably wont harm something in this case but it may in others. /me coughs in a manner that sounds very much like the words use case. The problem starts in the edit form, if you want yet to open another window, lets say you want to attach a file to the address which is opened in the edit window, within the opened edit window you open a HTML File Manager. So you have 3 windows open, the address view in the main web browser window, the edit form in a new window (without chrome) Every indication is that chromeless windows are on their way out. and the File Manager in another new window (without chrome). Wouldn't you use at least a modal window in case when you open the File Manager, if modal Windows would exist? Assuming the address can only be deleted by opening it in an address editing window and pressing delete, you have no use case in this situation, since the address can't be deleted until you return from the file manager. I would consider that this might be a problem in other situations, but I wonder if there aren't simple workarounds for it. The File Manager is just one case, I face this problem many times where for an external edit form it would be convenient to open a modal sub window. So your use case for modal windows is that there are many convenient situations where you'd want to open a modal window... So, Xforms may be a solution in that case if you don't require being the first window you open to be modal. By the way, I am simulating modal windows within the edit forms I use, but it is definitely a dirty hack to simulate multi web browser and multi os modal windows. Yeah, hacks like this run the risk of conflicting with native UI conventions, I'll give you that. However, it is widely accepted that modal UI is to be avoided anyway.
Re: [whatwg] [WA1] Attribute-based selection system
J. Graham wrote:
On Sat, 25 Jun 2005, Matthew Raymond wrote:
This is a specification of my selection system that I discussed over
several previous messages. A few modifications have been made since then, so
reference this rather than previous messages.
How would you allow different selections for different columns in a table
(i.e. I want to select one row per column)?
I can't think of a scenario where you can select any element within
each column and also have a semantic reason for elements in each column
to be on specific rows relative to elements in the other columns. If the
reason for the alignment is PRESENTATIONAL, however, CSS can accomplish
what you want with the following example:
| table
| tbody
| tr
| td
| ul selection=single auto
| li selectedItem 1/li
| li selectedItem 2/li
| li selectedItem 3/li
| /ul
| /td
| td
| ul selection=single auto
| li selectedItem 1/li
| li selectedItem 2/li
| li selectedItem 3/li
| /ul
| /td
| td
| ul selection=single auto
| li selectedItem 1/li
| li selectedItem 2/li
| li selectedItem 3/li
| /ul
| /td
| /tr
| /tbody
| /table
Also, you can simple put tables within tables. Modern browsers
handle rendering of nested tables quite easily.
Wait, there's a better way to handle this. Use col, but allow it
to be overridden by tr:
| table
| colgroup
| col id=selection1 selection=single auto
| col id=selection2 selection=single auto
| col id=selection3 selection=single auto
| /colgroup
| tbody
| tr id=colSelect selection=single auto
| th selectedCol 1/th
| thCol 2/th
| thCol 3/th
| /tr
| tr
| td selectedItem 1/td
| td selectedItem 1/td
| td selectedItem 1/td
| /tr
| tr
| tdItem 2/td
| tdItem 2/td
| tdItem 2/td
| /tr
| tr
| tdItem 3/td
| tdItem 3/td
| tdItem 3/td
| /tr
| /tbody
| /table
Still, I really think we're wandering into the Land That Use Cases
Forgot. This really strikes me as being three select-type controls
next to each other, with a table used to align everything for purposes
of presentation.
What would the DOM interface look like?
I'm no Javascript/DOM expert, but I'm thinking like this:
| interface HTMLElement : Element {
|attribute DOMString id;
|attribute DOMString title;
|attribute DOMString lang;
|attribute DOMString dir;
|attribute DOMString className;
|
| readonly attribute HTMLElement selectionContainer;
|attribute HTMLSelection selection;
|attribute boolean selectable;
|attribute boolean selected;
| };
|
| interface HTMLSelection {
| readonly attribute longlength;
| readonly attribute HTMLCollection elements;
|attribute longselectedIndex;
|attribute boolean disabled;
|attribute boolean multiple;
|attribute boolean childDefault;
|attribute boolean tree;
|attribute boolean allowZero;
| };
[whatwg] [WA1] Attribute-based selection system
This is a specification of my selection system that I discussed over several previous messages. A few modifications have been made since then, so reference this rather than previous messages. *** |selection| attribute *** selection = single | multiple [allowzero] [auto] [tree] The |selection| attribute specifies that the element is a container for selectable content. Possible values: * single - Mutually exclusive selection. Can't be used with multiple. * multiple - Multiple item selection. Cannot be used with single. * tree - Makes the current selection part of the parent selection. * allowzero - Allows for the selection of zero items. * auto - Default value for an immediate child |selectable| attribute is true. *** |selectable| attribute *** selectable = true | false The |selectable| attribute determines whether or not an element within a selection container is selectable. If the element does not have an ancestor with a valid |selection| attribute value set, then the |selectable| attribute is semantically meaningless. Possible values: * true - The element can be selected. * false - The element cannot be selected. Unless the immediate parent element is a selection container with the value auto specified, the default is always false. If an element has |selectable| set to true, then the |selectable| attributes for all descendants that are not children of descendant selection container elements are semantically meaningless. *** |selected| attribute *** The |selected| attribute now applies to all selectable elements in addition to the option element. *** Examples *** The following is a table with only the first cell of each row selectable: | table selection=single | tr | td selectable=true selectedItem 1/td | td ...contents... /td | td ...contents... /td | /tr | tr | td selectable=trueItem 2/td | td ...contents... /td | td ...contents... /td | /tr | tr | td selectable=trueItem 3/td | td ...contents... /td | td ...contents... /td | /tr | /table This is a multiple-selection list with the first item selected: | ul selection=multiple auto | li selectedItem 1/li | liItem 2/li | liItem 3/li | /ul Below is a multiple-selection list-based tree where only the leaves are selectable: | ul selection=multiple auto | li selectable=false | pItem 1/p | ul selection=multiple auto tree | liItem 1/li | liItem 2/li | liItem 3/li | /ul | /li | liItem 2/li | liItem 3/li | /ul Here is an example of a table where all rows but the header row are selectable: | table selection=single | tbody | tr | [...header row...] | /tr | tr selectable=true selected | [...first row of block two data...] | /tr | tr selectable=true | [...second row of block two data...] | /tr | tr selectable=true | [...third row of block two data...] | /tr | /tbody | /table Here's a different version of the above example: | table | tbody selection=single auto | tr selectable=false | [...header row...] | /tr | tr selected | [...first row of block two data...] | /tr | tr | [...second row of block two data...] | /tr | tr | [...third row of block two data...] | /tr | /tbody | /table
Re: [whatwg] Using X3D in XHTML documents
Matthew Raymond wrote:
| ?xml version=1.0 encoding=UTF-8?
| !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
| http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
| html xmlns=http://www.w3.org/1999/xhtml;
| xmlns:x3d=http://www.web3d.org/specifications/x3d-3.0.xsd;
| head
| title3D Model/title
| style type=text/css
| x3d:X3D {
| width: 100px;
| height: 100px;
| }
| /style
| /head
| body
| h1A 3D Cylinder Model/h1
| div
| x3d:X3D profile=MPEG-4 Interactive
| x3d:Scene
| x3d:Shape
| x3d:Appearance
| x3d:Material diffuseColor=0.0 0.5 1.0/
| /x3d:Appearance
| x3d:Cylinder/
| /x3d:Shape
| /x3d:Scene
| /x3d:X3D
| /div
| /body
| /html
Now that I think about it, wouldn't the following be valid also?...
| ?xml version=1.0 encoding=UTF-8?
| !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
| http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
| html xmlns=http://www.w3.org/1999/xhtml;
| head
| title3D Model/title
| style type=text/css
| x3d|X3D {
| width: 100px;
| height: 100px;
| }
| /style
| /head
| body
| h1A 3D Cylinder Model/h1
| X3D xmlns=http://www.web3d.org/specifications/x3d-3.0.xsd;
|profile=MPEG-4 Interactive
| Scene
| Shape
| Appearance
| Material diffuseColor=0.0 0.5 1.0/
| /Appearance
| Cylinder/
| /Shape
| /Scene
| /X3D
| /body
| /html
Re: [whatwg] Suggestion: Mouse Wheel events for Web Apps 1.0
Dave Hyatt wrote:
Safari in the latest Tiger update supports WinIE's mouse wheel
system.
Mozilla uses addEventListener[1], which is in DOM 2 and DOM 3. (DOM
3 even adds addEventListenerNS for different namespaces.) By contrast,
IE uses attachEvent, which is proprietary and doesn't allow you to
specify the the initial capture. As a result, I would NOT support using
attachEvent in any WHATWG standard, especially since it does not appear
functionally different from addEventListener. (Is there even an
IE-proprietary event listener method that supports namespaces?)
We also have a wheelDeltaX and wheelDeltaY so that
horizontal wheeling can be supported.
I'm thinking we should define new properties wheelDeltaX and
wheelDeltaY for MouseEvent. [2]
Chris Griego wrote:
That's incorrect. Both IE (since 5.5?) and Mozilla supports this.
Unfortunately they do it in different ways.
IE:
element.attachEvent(onmousewheel, function () {
document.title = window.event.wheelDelta;
});
Mozilla:
element.addEventListener(DOMMouseScroll, function (e) {
document.title = e.detail;
}, true);
Note that for attachEvent, you name the HTML attribute name and not
the actual DOM event type. Therefore, in DOM, if you wanted a listener
for a mousemove, you'd use the string mousemove and not onmousemove.
DOM also employs the method of using DOM at the beginning of strings
that don't correspond to the associated on attributes in HTML 4.01.
Since there is no official HTML5, this makes Mozilla's implementation
above the most standards correct.
I think I'd prefer something like mousewheel or DOMmousewheel.
I'm not sure a new |onmousewheel| attribute is called for, though,
because there might be semantic arguments against it. Anyone have a take
on this, by the way?
So, I guess I'd like to see this happen:
| element.addEventListener(mousewheel,
| function (e) { document.title = getWheelDelta(e); },
| true);
|
| function getWheelDelta(e) {
| return e.wheelDeltaY;
| }
I had planned to propose this at some point but hadn't gotten
around to it yet.
I'm hoping you aren't referring to the blatantly nonstandard IE
event model shown in Chris Griego's IE example...
[1]
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventTarget-addEventListener
[2] http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-MouseEvent
Re: [whatwg] Using X3D in XHTML documents
Jim Ley wrote: On 6/21/05, Matthew Raymond [EMAIL PROTECTED] wrote: Matthew Raymond wrote: Now that I think about it, wouldn't the following be valid also?... | ?xml version=1.0 encoding=UTF-8? | !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN | http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; | X3D xmlns=http://www.web3d.org/specifications/x3d-3.0.xsd; Of course not, there is no X3D element in the above dtd. Oh, I see. This was a suggestion in the XHTML 1.0 spec of how namespaces MIGHT be used. [1] I guess it's out of date. [1] http://www.w3.org/TR/xhtml1/#well-formed
Re: [whatwg] Nested MENU elements
Simon Pieters wrote: Will HTML5 allow nested MENU elements? HTML 4.01 Transitional doesn't allow nested MENU elements for some reason. I can't find anything about MENU nesting in the HTML 4.01 specification. Is that in an earlier specification? Current UAs treat the MENU element just like UL elements. Okay, that IS in the spec.[1] See test case [1]. It might be a good idea to make an explicit note about this at the definition of the element. [1] http://zcorpan.1go.dk/test/nested-menu.html I support the nesting of menu elements for the purpose of having submenus. Though many zealots would object to submenus because it's considered poor UI, I believe there are often situations where submenus are difficult or impossible to avoid. Currently, there's nothing in WA1 that would prevent nesting of menu elements, but there's nothing there to define how nested menu elements should be treated either. That needs to be fixed. Much of what we plan to do with menus is still up in the air, though. Feel free to contribute your own thoughts. [1] http://www.w3.org/TR/html4/struct/lists.html#edef-MENU
Re: [whatwg] [WA1] sl - The Selection List element
James Graham wrote:
Matthew Raymond wrote:
J. Graham wrote:
On Tue, 7 Jun 2005, Matthew Raymond wrote:
[Snip!]
| selectgroup classname=myclass1 multiple=False /
|
| table
| tbody
| tr
| [...header row...]
| /tr
| tr class=myclass1
| [...first row of block two data...]
| /tr
| tr class=myclass1
| [...second row of block two data...]
| /tr
| tr class=myclass1
| [...third row of block two data...]
| /tr
| /tbody
| /table
(Above example left for other readers to reference.)
This seems like a good way to handle it at first, but there are
several problems, not the least of which is the fact that you're
creating a new element that amounts to a semantic styling tag.
Eh? What's a semantic styling tag?
Well, you use the |class| attribute for styling purposes.
Therefore, assuming selection is semantic (and I feel it is, since
it's already used by select and such), then the selectgroup
element is effectively styling members of a class with new semantics
they otherwise wouldn't have.
Well yes, sort of. But I don't see that as being incompatible with the
way that class is supposed to be used. The HTML 4 spec is less than
entirely clear but it does say class can be used for general purpose
processing by user agents.
I don't think that new markup to assign semantics via classes is
what they meant by that. They're talking about allowing user agents to
assign additional semantics to predefined class names. You're talking
about creating the first element in a sublanguage of HTML to perform
semantic styling.
This seems to be an example to general
purpose processing - class groups the elements and we attach behavior
to a particular group. It's certianly much less of a crime than anything
that may appear under http://whatwg.org/specs/web-apps/current-work/#classes
There's not much there right now, but it seems the spec will allow
user agents to use predefined class names in a predefined namespace (via
|profile|) for special processing. In every case, the profiles and
classes are predefined and hardcoded into the user agent.
Why would we need Javascript for selection? My examples with sl
and switch didn't use Javascript at all. (Of course, my examples
assumed that clicking on a link to a section inside switch would
make that section active, which isn't in the spec, as far as I know.)
My point is, if there's no way to interact with the selection except via
script, it makes no sense to provide anything other than script-based
interfaces to it.
Er...but I have no intention of making selection only accessible via
script. My system defines the selection type (single, multiple, et
cetera) and what can be selected in markup, then allows the user to
change the selection directly without the use of Javascript.
Unless there are actual declarative things to do with
the selection in the spec (such as your suggestion), I'm very much
opposed to having _any_markup for this problem.
So would I, because then you could just use Javascript to assign a
selected class and style the class.
Could one use a CSS/mozilla-XBL like solution instead (i.e.
.myclass {select:multiple;} ) - maybe not if we consider this to be
'semantic' - but what does sXBL (or whatever it's called now) do?
Selection is clearly not presentational. You might call it
behavioral, but it's definitely not presentational, because a
selection in a form control can be submitted. Therefore, selection
should NEVER be defined in CSS.
Sure. This is why I'm wondering how sXBL deals with binding to elements.
Imagining that the table in the example had id=tableid One could do
something like:
selectgroup multiple=False bind=table#tableid td /
Actually, I think you could probably use XBL to apply my system to
elements via CSS binding. Having selectors in HTML seems kinda scary to
me...
or
bindings
table#tableid td {
select:multiple;
}
/bindings
You can bind CSS using sXBL/XBL2???
or similar things with XPath. But I'm ad-libing here and am becoming
increasingly worried that the whole thing looks like XForms.
Actually, the whole thing looks like an HTML version of semantic CSS
properties.
I'd like to note that there is a lot of potential abuse with the
selectgroup element. Here's an example:
| selectgroup multiple=false bind=table#tableid td /
| selectgroup multiple=true bind=myclass1 /
| selectgroup multiple=true bind=myclass2 /
|
| table id=tableid
| tr
| td ...contents... /td
| /tr
| tr
| td ...contents... /td
| /tr
| tr
| td class=myclass ...contents... /td
| /tr
| tr
| td class=myclass ...contents... /td
| /tr
| /table
|
| p
| There's nothing as useless as a lock with a
| span class=myclass1voice print/span.
| /p
|
| ul
| li class=myclass1Item 1/li
| li class=myclass2Item 2/li
| li class=myclass2Item 3/li
| /ul
Note that such abuses aren't
Re: [whatwg] [WA1] sl - The Selection List element
James Graham wrote: Aankhen wrote: Reusing class has the added advantage that authors are already familar with grouping items through the class attribute and in particular, are already familar with attaching style through class. This should make for a shallow learning curve as using new features will be a simple matter of reusing existing markup habits. I understand why it is preferable. I'm just a little wary of attaching semantics to specific classes, since they could conceivably collide with user classes. One possible solution is to make them as long as possible, so that the likelihood is much lower; however, that reduces their usefulness, IMHO. I totally agree. I'm not really suggesting attching semantics to particular class names (although others are, in other places - the needs some simple form of namespacing imho). I'm more suggesting that we have a mechanism to attach predefined behaviors (such as selection) based on class name. So I guess we could have an element like selectgroup classname=myclass multiple=False / or somesuch to attach a behavior to all the elements in class myclass. I presume you're referring to something like this: | selectgroup classname=myclass1 multiple=False / | | table | tbody | tr | [...header row...] | /tr | tr class=myclass1 | [...first row of block two data...] | /tr | tr class=myclass1 | [...second row of block two data...] | /tr | tr class=myclass1 | [...third row of block two data...] | /tr | /tbody | /table This seems like a good way to handle it at first, but there are several problems, not the least of which is the fact that you're creating a new element that amounts to a semantic styling tag. Another problem is that this can cause serious problems if someone forgets to put the class name inside a template, thus making all items created by a user unselectable. Or you could have situations where simple misspellings make things unselectable. Now suppose we let the templating system work for us... | table | tbody | tr | [...header row...] | /tr | tr repeat=1 selected=selected | [...first row of block two data...] | /tr | tr repeat=2 | [...second row of block two data...] | /tr | tr repeat=template repeat-selection=single | [...third row of block two data...] | /tr | /tbody | /table In this manner, we not only make all blocks associated with a template selectable, but we also define the type of selection, and all without adding new elements or forcing the author to create new classes. The downside of this is that we're forced to use templates for selection. One solution is to create a property that applies to a parent element that makes all of the immediate children selectable: | ul selection=single | il selected=selectedItem 1/il | ilItem 2/il | ilItem 3/il | /ul In the case of tables, it might look like this: | table | tbody | tr | [...header row...] | /tr | /tbody | tbody selection=single | tr selected=selected | [...first row of block two data...] | /tr | tr | [...second row of block two data...] | /tr | tr | [...third row of block two data...] | /tr | /tbody | /table Or in HTML: | table | tbody | tr [...header row...] | tbody selection=single | tr selected [...first row of block two data...] | tr [...second row of block two data...] | tr [...third row of block two data...] | /table Of course, this still leaves cases where you want certain children to be unselectable -- oh, wait -- unselectable!!! | table | tbody selection=single | tr unselectable [...header row...] | tr selected [...first row of block two data...] | tr [...second row of block two data...] | tr [...third row of block two data...] | /table Perhaps in cases where tbody and the gang aren't specified, the properties could be passed straight to the implied tbody: | table selection=single | tr unselectable [...header row...] | tr selected [...first row of block two data...] | tr [...second row of block two data...] | tr [...third row of block two data...] | /table Of course, this doesn't necessarily support selection in a tree-like structure, but it could probably be extended to support it: | ul selection=multiple tree | il unselectableItem 1 | ul selection=multiple | il selectedItem 1a/il | ilItem 1b/il | ilItem 1c/il | /ul | /il | ilItem 2/il | ilItem 3/il | /ul Any thoughts on all of this?
Re: [whatwg] [WA1] sl - The Selection List element
J. Graham wrote:
On Tue, 7 Jun 2005, Matthew Raymond wrote:
[Snip!]
| selectgroup classname=myclass1 multiple=False /
|
| table
| tbody
| tr
| [...header row...]
| /tr
| tr class=myclass1
| [...first row of block two data...]
| /tr
| tr class=myclass1
| [...second row of block two data...]
| /tr
| tr class=myclass1
| [...third row of block two data...]
| /tr
| /tbody
| /table
(Above example left for other readers to reference.)
This seems like a good way to handle it at first, but there are several
problems, not the least of which is the fact that you're creating a new
element that amounts to a semantic styling tag.
Eh? What's a semantic styling tag?
Well, you use the |class| attribute for styling purposes. Therefore,
assuming selection is semantic (and I feel it is, since it's already
used by select and such), then the selectgroup element is
effectively styling members of a class with new semantics they otherwise
wouldn't have.
What I'm saying is that, if we want
things like selection to work declaratively, one possibility is to use an
element to bind certian classes to a behavior. There are, of course, other
possibilities - is a declarative solution even necessary? What could a UA
do with selection (or drag/drop) information if js is turned off?
Why would we need Javascript for selection? My examples with sl
and switch didn't use Javascript at all. (Of course, my examples
assumed that clicking on a link to a section inside switch would
make that section active, which isn't in the spec, as far as I know.)
Could one use a CSS/mozilla-XBL like solution instead (i.e.
.myclass {select:multiple;} ) - maybe not if we consider this to be
'semantic' - but what does sXBL (or whatever it's called now) do?
Selection is clearly not presentational. You might call it
behavioral, but it's definitely not presentational, because a selection
in a form control can be submitted. Therefore, selection should NEVER be
defined in CSS.
Also, don't forget that you break the page if you turn of CSS (like
you can do in Firefox).
Another problem is that this
can cause serious problems if someone forgets to put the class name inside a
template, thus making all items created by a user unselectable. Or you could
have situations where simple misspellings make things unselectable.
Well, er, yes. In the same way that a misspelling in any piece of
javascript can prevent that code working, a misspelling in a class
attribute can prevent the expected style selectors matching an element...
These things are typically solved by testing. Why is this suggestion any
harder to test than any other part of the language?
You somewhat have a point, but points of possible failure should
always be minimized whenever possible. Compare the following...
Original list:
| ul
| ilItem 1/il
| ilItem 2/il
| ilItem 3/il
| /ul
List with selectgroup:
| selectgroup classname=myclass1 multiple=false /
| ul
| il class=myclass1Item 1/il
| il class=myclass1Item 2/il
| il class=myclass1Item 3/il
| /ul
List with |selection| attribute:
| ul selection=single
| ilItem 1/il
| ilItem 2/il
| ilItem 3/il
| /ul
Not that with your system you have to add an extra element and a
|class| attribute for every item. Note also that the class has virtually
no value for styling, since you can use :selected in both cases:
| ul il:selected { /* Selected item styling. */ }
While misspelling is a potential source of error in my system, there
a small, finite set of attribute values, so unless you hand-code the
HTML, your HTML editor will ensure that misspellings are not an issue.
By contrast, the |class| attribute can be anything. It makes more sense
to have selectgroup as an attribute, since you have to declare the
group name for every item anyway, and even then you have the same
problem: the user has to type in the |selectgroup| for every item.
Re: [whatwg] Re: About XHTML 2.0
Christoph Päper wrote: You say that and some others share that point of view, but I (and probably others) disagree. It is true that 'div' or 'class' don't provide semantics directly, but they do indirectly: Everything inside a 'div' belongs together somehow and everything that shares a class (inside a document instance) is related to each other somehow. You cannot know /how/, but /that/. The div (as well as span) does indeed have semantic meaning in that it can group things. However, in the case of replacing hr, I don't see how this semantic information can actually be used to benefit the user. It's certainly useless on modern browsers from a presentation standpoint if I turn CSS off. If one doesn't like sectiondiv class=foop/+/div+/section for the added level in the document tree, then he might use the semantically similar sectionp class=bar/+p class=baz/+/section. Huh? All paragraphs that share a perspective or language or something are logically linked, they belong to one group (or class) and maybe to others, too. It can make sense to express this in mark-up. Then it's easy (depending on your styling language of choice) to add visual (or aural) clues to make the changes in perspective (or language) visible. That doesn't have to be a more or less fancy rule or pause, but may be a change in font, color, sound etc. If they are wrapped together by any element, they definitely are grouped together. By dropping hr, we're forcing a situation by which the web author has to add structural markup that's of little or no use to him/her or the user. In fact, I wouldn't be surprised if web authors deprived of an hr element simply did this: | pParagraph 1/p | p class=hr* * */p | pParagraph 2/p An hr is equivalent to a p with the content Meanwhile, somewhere else... or similar (From someone else's point of view..., At another time...). No, it's not. You are connecting it with the succeeding element instance, but it's not. But your whole argument is that a separator is nothing more than the end of one section and the start of another one. Therefore, being the start of the next section, it's perfectly valid to render it as connected to the text in the next section. Anyhow, if it was, why wouldn't you use a 'p' with that content or an empty one? Because you're leaving it up to the user agent to pick a presentation, just as you would rely on the user agent to decide how em should be presented. pqNo!/q said Fred./p hr pThe tree stood alone./p +--+ +--+---+ | _ | | Meanwhile... | | | No! | +--+ | | \/^^^ | | /|\ | | o | | /|\ | | -+- | | | | | / \ | | | | +--+ +--+ my point is that the hr here is a unit on par with a paragraph, So why is it rendered embedded into the box of one of the paragraphs? Shouldn't it be a child of it then? Two elements can overlap without one being a child of the other. it's not an artefact of an implied higher level grouping. Show me the whole text, I'll show you the higher level grouping. Perhaps, but you force authors to identify those groupings and add structural markup and CSS for them when you can just stick an hr in there that will work even with the CSS turned off? If we didn't have hr, p* * */p Or p/ or pimg src=fancy-divider alt=* * */p. Does this provide the semantics? No, because they lack the semantics of hr. (IMHO it does not, because 'hr' or 'plot' are one level higher than the 'p', but) if so, why should we retain that limited 'hr' element type, which could ambiguously be in par with other elements than 'p' (as in /sectionhrsection)? There's nothing about hr that forces you to use it. You've already given examples that use existing markup. In cases where you don't feel it should be used, don't use it. I really don't think: pqNo!/q said Fred./p /plot plot pThe tree stood alone./p ...would be better than hr, I do. (Although I'm fine with using 'div' for this.) in fact I think it would be unnatural from an authoring perspective. I, on the opposite, think that it's unnatural to mark the end of one thing and the start of a second, but neither the start of the first nor the end of the second. Oh really? So you're saying that if I have some text... | Paragraph 1 | | Paragraph 2 | | Paragraph 3 | | * * * | | Paragraph 4 | | Paragraph 5 | | Paragraph 6 ...it's more natural for an author to do this... | section | pParagraph 1/p | pParagraph 2/p | pParagraph 3/p | /section | section | pParagraph 4/p | pParagraph 5/p | pParagraph 6/p | /section ...plus the additional CSS overhead (which I'm still confused about, by the way) instead of this: | pParagraph 1/p | pParagraph 2/p | pParagraph 3/p | hr | pParagraph 4/p | pParagraph
Re: [whatwg] Using X3D in XHTML documents
Ian Hickson wrote: On Sun, 5 Jun 2005, Matthew Raymond wrote: My concern is that the various working groups (Web3D, WHATWG, et cetera) will play pass the buck on this issue. Can we create a generic spec for displaying 3D information in a 2D window? We could allow the X3D spec or other specs to override if they needed to. We can put something in our rendering section (not yet existant) that gives recommended behaviour for X3D-in-CSS until the X3D and CSS groups get around to doing so themselves, sure. But personally I would have no idea how to do so, so someone is going to have to write draft text. :-) I suppose I can write something up as a starting point... The div element is not the right element for what? Well, the div element is meaningless, so it isn't the right element for anything, unless it has some sort of semantics hung off the side of it (e.g. if it has the title= attribute or the lang= attribute or some such). Actually, I was wondering why I put the div in my example in the first place, and what I didn't understand is why you thought it was of any significance within the example.
Re: [whatwg] Using X3D in XHTML documents
Ian Hickson wrote:
On Thu, 2 Jun 2005, Matthew Raymond wrote:
Given this new information, I would like to know of the following is
an acceptable use of X3D within an XHTML document:
| ?xml version=1.0 encoding=UTF-8?
| !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
| http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
| html xmlns=http://www.w3.org/1999/xhtml;
| xmlns:x3d=http://www.web3d.org/specifications/x3d-3.0.xsd;
| head
| title3D Model/title
| style type=text/css
| x3d:X3D {
| width: 100px;
| height: 100px;
| }
| /style
| /head
| body
| h1A 3D Cylinder Model/h1
| div
| x3d:X3D profile=MPEG-4 Interactive
| x3d:Scene
| x3d:Shape
| x3d:Appearance
| x3d:Material diffuseColor=0.0 0.5 1.0/
| /x3d:Appearance
| x3d:Cylinder/
| /x3d:Shape
| /x3d:Scene
| /x3d:X3D
| /div
| /body
| /html
I guess so. Some spec somewhere will probably need to state that an
X3D
element introduces a rectangular surface and then should describe how to
determine its 2D intrinsic dimensions and/or intrinsic aspect ratio.
My concern is that the various working groups (Web3D, WHATWG, et
cetera) will play pass the buck on this issue. Can we create a generic
spec for displaying 3D information in a 2D window? We could allow the
X3D spec or other specs to override if they needed to.
The next step, I guess, is to see if any Web browser vendors want to
implement X3D! Is the X3D spec stable?
(Note that in the above the selector is wrong and the div is probably
not the right element, but that's another story.)
Oops!
| x3d|X3D {
| width: 100px;
| height: 100px;
| }
The div element is not the right element for what? I'm not even
If this is acceptable, does this negate the value of a potential 3d
context for canvas in XHTML?
No, there are needs for both declarative 3D and for direct-mode 3D.
I've already come to that conclusion elsewhere in this thread.
Re: [whatwg] Using X3D in XHTML documents
James Graham wrote: Matthew Raymond wrote: If this is acceptable, does this negate the value of a potential 3d context for canvas in XHTML? Presumably X3D:3D canvas is equivalent to SVG:2D canvas. Took me a moment to get this, for some reason. You're saying that X3D is to a canvas with a 3d context as SVG is a canvas with a 2d context. Yeah, that's pretty much the idea. Right now, I'm leaning towards the idea of X3D being used for general purpose 3D support in XHTML, with a low-level 3d context for canvas (probably a wrapper for OpenGL|ES, except less API specific). I don't see a high-level 3d being useful in XHTML, since X3D is already defined and has code to support it. X3D integration into a browser would take less time than specifying and coding a totally new API from scratch. This leaves us in limbo for HTML, though. I suppose the best solution would be that every browser that supports X3D, either natively or by plug-in, should support the following markup: | object data=TheEarth.x3d type=model/x3d+xml | img src=TheEarth.gif alt=A picture of the planet Earth | /object We could also define a standard interface for accessing the external object's DOM (if that hasn't been done already). Being able to manipulate the DOM for an X3D file in HTML would be the next best thing to compound XHTML/X3D documents. Your thoughts?
Re: [whatwg] Using X3D in XHTML documents
Matthew Raymond wrote: We could also define a standard interface for accessing the external object's DOM (if that hasn't been done already). Being able to manipulate the DOM for an X3D file in HTML would be the next best thing to compound XHTML/X3D documents. Oops, it IS already defined: http://www.w3.org/TR/2002/CR-DOM-Level-2-HTML-20021007/html.html#ID-38538621 We could simply require that .contentDocument return the X3D document for all browsers that have support for X3D (via either a plug-in or natively).
Re: [whatwg] Re: About XHTML 2.0
Mikko Rantalainen wrote:
Ian Hickson wrote:
On Sat, 21 May 2005, Anne van Kesteren wrote:
Why doens't SECTION suffice? They are sections separated by decoration.
At least, that is how it appeals to me.
They're not really sections. The chapter is the section, these are
paragraphs together in the same chapter, with a divider between some of
the paragraphs.
I read a lot of fiction books and when I come across a * * * it reads to
me like a paragraph, saying Meanwhile, in a different part of the
universe:; it doesn't read as end section. new section:.
I read the * * * part exactly the same way. And I consider your
quoted text to be the header for that sub-section even though it's
omitted from the output. I feel that the correct markup to use would be
section!-- chapter starts here --
hYet another chapter/h
section!-- 1st point of view, really a subsection --
h class=undisclosedIn the Jack's basement/h
...
/section
section!-- presentation adds * * * here --
h class=undisclosedMeanwhile in the Bill's room/h
...
/section
/section!-- chapter ends here --
So what you're saying is that if I want this...
| section!-- chapter starts here --
| hYet another chapter/h
| p[Something about Jack.]/p
| hr
| p[Something about Bill.]/p
| /section!-- chapter ends here --
...then I have to do this?...
CSS:
| .chapter section + section:before {
| content: * * *;
| text-align: center;
| }
HTML:
| section class=chapter!-- chapter starts here --
| hYet another chapter/h
| section!-- 1st point of view, really a subsection --
| h class=undisclosedIn the Jack's basement/h
| p[Something about Jack.]/p
| /section
| section!-- presentation adds * * * here --
| h class=undisclosedMeanwhile in the Bill's room/h
| p[Something about Bill.]/p
| /section
| /section!-- chapter ends here --
Actually, there are situations where the above would be suboptimal,
based on how :before and content are defined CSS2.1. For instance, if
you put a border around each section, the border would be rendered
around the * * *.
Note that if the above CSS is incorrect, it really just proves my
point: using CSS in place of hr is a pain for webmasters. Note also
that without CSS support (or if the separate CSS file isn't loaded for
some reason), you probably won't see a separator rendered unless that's
the default behavior for rendering sibling sections.
This isn't just inconvenient from a styling and markup standpoint,
though, although clearly it increases the amount of HTML and CSS you
need. The big problem is that it places a semantic burden on authors
that currently doesn't exist in HTML. With current HTML, I just need to
put the paragraphs from the source text in p elements and use hr
where the source text has a visual separator. Doing away with hr means
at the very least that you're forced to put everything in section
elements when you previously didn't. Add to that the fact that authors
now have to know how to style the sections in order to get the separator
and you have a serious learning curve.
In my opinion, this is the correct sematics for the content. To
increase excitement for the reader, some of the content is hidden
during the presentation. If you feel that hiding the information is
part of the semantics in this case (arguably that may be true), just
drop all the h elements with class undisclosed above.
If I were transferring the text of a book into HTML, I would not
think to put in the headings in the first place, unless they were in the
book itself, and clearly a situation where you have * * * is one where
you won't have headings.
I think this is an example of why an h element shouldn't be
required inside a section element.
IMHO.
I'm with you on that one.
To put it another way, sections are things that you can put a title to.
There's no title you can put to a group of paragraphs separated from other
groups of paragraphs in the same chapter of a work of fiction, in my
experience. It's just the same chapter, with the narrative exploring
different characters or scenes.
I think you can always put a title to a group of paragrahps. It's
just that sometimes (often?) you decide to leave it out for brevity
/ clarity / excitement / whatever.
Decide to leave it out? You're assuming people even think of it in
terms of sections. We've gotten so used to narratives that cut from one
location to the next, or go back and forth between places or events or
characters, that we don't necessarily think of it in terms of different
sections. You're presuming that every time an author creates what could
be described as a section, it's done on purpose. In reality, it's may be
largely subconscious, and the author may not even think about it until
they need a separator.
[whatwg] [WA1] sl - The Selection List element
I'm proposing a new element named sl. This element is a list where
the list items become selected when the items or their child elements
are activated (i.e. someone clicks on them). Here's an example:
| sl
| lia href=#s1Section 1/a/li
| lia href=#s2Section 2/a/li
| lia href=#s3Section 3/a/li
| /sl
In the example above, you have a list of links where the containing
list item is selected when someone clicks on the link. The presentation
of the selected items is handled through CSS:
| li:selected { /* Your style here. */ }
By default, the selection would be mutually exclusive. In other
words, the default for clicking on a list item is that it would become
the ONLY selected item, similar to select. Also similar to the
select element, you could specify a |multiple| attribute to select
more than one item:
| sl multiple=multiple
| liName 1/li
| liName 2/li
| liName 3/li
| /sl
If multiple items are selected, and the user performs a drag
operation on a list item, the drag would automatically be performed on
all list items selected rather than just the list item being dragged.
If you want to use this element to create a tabbed control, it would
look like this:
HTML:
| sl
| li selected=selecteda href=#s1Section 1/a/li
| lia href=#s2Section 2/a/li
| lia href=#s3Section 3/a/li
| /sl
|
| switch
| section active=active id=s1[...]/section
| section id=s2[...]/section
| section id=s3[...]/section
| /switch
CSS:
| sl li { appearance: tab; display: tab }
| sl li:selected { display: front-tab }
The idea is that a hyperlink to a section within a switch will
automatically set that section as active. Yes, I know that this makes
tabbox pointless, but I don't see tabbox as having any serious
advantages, especially when you have switch. With a very small amount
of Javascript and CSS, you can make an unordered list and a switch
behave in exactly the same manner as tabbox, so what do we need
tabbox for?
That's all I have to say for now. I'll probably have more later, but
I just want to get some feedback right away.
Re: [whatwg] [WA1] sl - The Selection List element
R.J.Koppes wrote: I don't really see the advantage above using ordinary lists or form controls and css pseudoclasses like :target ,:focus and :active Let's look at these pseudoclasses one at a time... The :target pseudoclass only applies to an element that has its |id| attribute as part of the URL. If it isn't in the URL, or the URL changes so that the |id| is no longer in the URL, then the styling is not applied. Focus is lost when you click on something else on the page, so you can't use :focus to style a list item as being a selected tab. From the CSS3 Selectors spec: | The :active pseudo-class applies while an element is being activated | by the user. For example, between the times the user presses the mouse | button and releases it. So clearly :active is useless once your mouse button is up. The only real way to use a list for tabs without Javascript is to have a list that maintains items as being selected. So, we either provide a way to do that with current lists, or create a new list. If you can think of a way that existing lists can be given a means of item selection, then that's fine as well. Here's a thought on that: | ul selection=single | li selected=selecteda href=#s1Section 1/a/li | lia href=#s2Section 2/a/li | lia href=#s3Section 3/a/li | /ul
Re: [whatwg] Web Applications and 3D
Jim Ley wrote: On 4/29/05, Matthew Raymond [EMAIL PROTECTED] wrote: The examples I've seen with regard to DirectAnimation are done through an object and use an ActiveX control, so standardizing such an interface isn't appropriate. Could you explain why? ActiveX is just the mechanism windows uses for componentisation - WHAT-WG is already standardising things implemented as ActiveX in IE. Plug-ins are by their very nature optional. Why would we want to move functionality into object elements, which are by definition external objects like plug-ins? HTML should NEVER specify the functionality of an external component, regardless of how many machines that component is installed on. Besides, if UA vendors really wanted to make DirectAnimation specifically work under their own user agents, they wouldn't need a WHATWG spec to tell them to do so. If you're saying that the creation mechanism for a 3D canvas is wrong - there's something wrong with using OBJECT, and we need to use CANVAS3D instead, then perhaps you might have a point, I'd like to hear a lot more motivation for inventing new elements for this, given the problems with new elements highlighted so often by Ian and others. However the creation is one minor part of the 3D API, and it's the API I was talking about. The object element specifically suggests an external component. Therefore, any semantically appropriate implementation that uses object would be a plug-in, and last time I checked plug-ins were optional. By contrast, canvas (and related suggestions) would be implemented directly in user agents, ensuring that all user agents that adhere to the standard have support, regardless of what plug-ins are installed. Some have suggested not limiting the canvas graphics APIs to a single element called canvas, but instead allowing the APIs to work on any element, or a specific set of elements. In either case, the API and the contexts would be largely the same, so it doesn't matter from the standpoint of developing the 3d context. We may want to be able to implement the 3d context for canvas on top of DirectAnimation. Could you describe why this might be a motivation, what do you see as so lacking in the current implementation that it's not takeable as a whole? Generally, the use of object is what I object to. In theory, you could create a Microsoft-specific ms-3d-direct-animation context, for instance, that you could use with canvas to do the same thing as the use of the object element does now. I may try to include parts of the DirectAnimation APIs in the 3d context. I'm going to have to research it first, though. As always, I'm still waiting to hear the use cases for both 2D and 3D javascript drawing - Quake like games which is the only example I've heard so far, may be a use case, but it's not yet been explained why an HTML document is appropriate for such a game. I've already suggested the use of 3D for previewing a custom ordered product such as a motorcycle. All drawn in client-side javascript? - remember the use cases I'm looking for are not use cases for 3D, but for use cases for a 3D canvas in a webpage, that has no state, and relies wholly on all the information being drawn by javascript onload or later? I do not accept that the above is a practical use case. How so? A 3d context would undoubtedly have functions for loading complete textures and models from files. Even if you assume the files are huge and take an enormous amount of time to load, how is using a plug-in that much better for the user experience? Also, there have been suggestions to base much of the 3d context on OpenGL ES, which has extensive support for vertex arrays. It is likely that we will design the context to use arrays extensively. It won't be a situation where you have to issue a command to draw every single polygon and specify every color and texture coordinate. Once you set up some arrays, you'd simply use a DrawArrays method or something like that. Perhaps you want to see a 3D representation of the hotel room you plan to book. Same for real estate. If you're ordering a ticket from a concert, wouldn't it be nice to see what the stage will look like from your seat? Need I go on? Yes, because none of these are being addressed by a 3d drawable canvas and a javascript API, the simple creation of any of these is not appropriate to a programming language, they are all declaritive, and the WHAT-WG individual has made it clear that a declaritive 3D mechanism is not on the agenda. If that is all that we get, then none of those use cases will be fulfilled. If by declarative you mean like X3D, then WHATWG clearly shouldn't add such markup to HTML because it would duplicate the work of another group unnecessarily. I really don't see where you're going with this, though, since DirectAnimation isn't much more declarative than the canvas solution. While I think, for some purposes, X3D might be better suited, I fail to see how a 3D drawing
Re: [whatwg] Web Applications and 3D
Ian Hickson wrote: On Thu, 28 Apr 2005, Matthew Raymond wrote: The problem with a canvas solution is that the entirety of the 3D data has to exist within the canvas element. If you want multiple elements in the markup to map to a single 3D window, then canvas doesn't really work. Right, but my question is what's the use case for having objects for your 3D world exist in the DOM? Well, in situations with Javascript off, the benefits are obvious. There's also the potential to use XBL to apply special behavior to specific tags. For instance, instead of having a static Sun in the sky, you could have it rise and set by using XBL to pull in code that moves the model and lighting around. Having said that, there are probably use cases for declarative 3D, just like there are with declarative 2D. And for those you would use a dedicated markup language, just like you use SVG for 2D graphics. My point was that I'd like to see a CDF (not the CAD kind, but the W3C kind) that uses XHTML + X3D, or XHTML + CSS + XBL2 + X3D. While I think it has a lot of potential, I don't know enough about how the respective standards to determine would work together. (This is partly because of my lack of knowledge of XBL2 and X3D...) If it wouldn't work together, it indicates a problem in the X3D spec (or the lack of an appropriate 3D declarative markup language). Creating a 3D markup language is somewhat outside the purview of this working group, though. I'm not saying there's a problem with X3D. I'm just trying to make sure there is a clear idea of how to make XHTML + X3D compound documents. In other words, I'm trying to find the weak link, if there is one, and at the moment that seems to be a lack of examples on the Internet. I already knew the HTML. I was kinda hoping to see the CSS/XBL2 part of that equation. That's the part I'm confused about. Does XBL2 have a CSS binding property like XBL 1.0? XBL2 doesn't exist yet, but the idea is it will have that, yes. Good. I don't see nearly as strong a use case for XBL without such binding. I don't see people writing 3D games using a declarative format. Maybe for the models, as external files that are slurped in (just like external bitmaps are used as sprites with 2D canvas), but that's very different from having the 3D in the document. My thinking is that a 3d context for canvas may require Javascript as complex as a 3D rendering engine built on top of OpenGL. By contrast, something like X3D would require only DOM manipulation, because the rendering engine would be either a plug-in or part of the UA. X3D could also use XBL to achieve special effects that a programmer would otherwise have to code into their canvas-based engine. Imagine LOD, particle effects, fog, et cetera, turned on and off by simply selecting an alternate stylesheet. (Well, I suppose you could do that stylesheet thing with canvas and XBL, but it wouldn't be pretty.) I mean stuff like having windows that get smaller when they're further back in the Z-order. Perhaps there's a fog effect. You could have various section elements rendered within a 3D environment, where the user looks in a specific direction or in a specific place to see the section inside a 3D environment. Stuff like that. That'd just be up to the UA, really. No, I meant as in the web author implementing that with web standards, not the UA adding those effects to vanilla HTML5.
[whatwg] XHTML + X3D (was Re: Web Applications and 3D)
Ian Hickson wrote: On Fri, 29 Apr 2005, Matthew Raymond wrote: Well, in situations with Javascript off, the benefits are obvious. I don't mean to be obtuse, but: they aren't to me. I guess I could imagine wanting declarative 3D for when you want to show someone around your office or something like that, but I can't say I've seen much demand for that, and even less integrated with HTML. In any case, that would be something to be addressed by another specification, like X3D. HTML (specifically XHTML) already supports integrating with other namespaces. I'm not suggesting integration with HTML5. I'm perfectly happy with using X3D (or some other separate language, like XGL). My concern is the lack of analysis of how these technologies fit together. It's like fitting an engine to an airframe. I don't want the engine to necessarily be part of the airframe design, but they still have to work together, and you won't know where the problems are until you try fitting them together. There's also the potential to use XBL to apply special behavior to specific tags. For instance, instead of having a static Sun in the sky, you could have it rise and set by using XBL to pull in code that moves the model and lighting around. What sky? :-) I haven't seen many applications with skies... I'll try to come up with a less game-like example next time... Question: Game != Application? I'm not saying there's a problem with X3D. I'm just trying to make sure there is a clear idea of how to make XHTML + X3D compound documents. In other words, I'm trying to find the weak link, if there is one, and at the moment that seems to be a lack of examples on the Internet. The biggest problem with integrating X3D and XHTML is, as far as I can tell, the lack of a namespace to identify X3D content. (This is similar to the problem preventing Docbook integration.) Good, now we're getting somewhere. Let's say X3D did have a namespace, like x3d. Could we use x3d:x3d or x3d:scene as the container/viewport? If you want declarative 3D integrated into the Web browser pipeline, alongside the DOM, JS, XHTML, SVG, CSS, XBL, etc, I encourage you to bring this up with the Web3D consortium. Very well. I'll also look into competing languages being developed.
[whatwg] Web Applications and 3D
I've been pondering how someone would have 3D graphics inside a Web application using current web standards and some in development (XBL2, HTML5, et cetera), and while I have a general idea, I'm not exactly sure how it would work. One method would be to give canvas a 3d rendering context. This would solve some problems, but what happens when you want objects for your 3D world to exist in the DOM? What happens when you want 3D effects that change when you use a different stylesheet? Don't we need a method of including 3D graphics for styling that doesn't use Javascript? Let's look at possible solutions: 1) canvas - This requires you to manage your 3D objects in Javascript or some other scripting language. It also means defining a 3d context, which could get complicated _really_ fast. 2) XHTML + CSS + XBL2 + X3D - This would allow the greatest flexibility, but it comes with a serious learning curve. Also, it wouldn't work with HTML. 3) HTML + CSS3D - The idea is to extend CSS to allow for 3D backgrounds and such. The trouble with this is that it's hard to change the 3D content dynamically. I'm leaning toward either 1) or 2). I suspect the second choice would be better in the long run, but what I don't understand is what a page using all these standards would look like. If someone is up to the challenge, I'd like to see someone come up with examples for the following: 1) A Web standards version of Microsoft's Flipin' CD Button example. 2) An example of something similar to Quake done entirely as a web application, with a HUD. 3) An example of a simple 2D GUI with 3D effects as a web application. Not that I'm looking for very basic proof-of-concept examples and not fully developed web apps. Any takers?
Re: [whatwg] Web Applications and 3D
Ian Hickson wrote: On Thu, 28 Apr 2005, Matthew Raymond wrote: I've been pondering how someone would have 3D graphics inside a Web application using current web standards and some in development (XBL2, HTML5, et cetera), and while I have a general idea, I'm not exactly sure how it would work. The current idea is to do the same for '3d' as for '2d', probably using an OpenGL ES API subset, tweaked to be appropriate for use from JavaScript. Unfortunately I know very little about 3D graphics myself so someone else is going to have to actually define the API. I've done some work with OpenGL. I'd be happy to write a first draft. ...what happens when you want objects for your 3D world to exist in the DOM? What happens when you want 3D effects that change when you use a different stylesheet? What's the use case? The use cases that people have raised for 3D so far are primarily games (as in Quake-like things). In those, you don't really need to have a DOM representation, and stylesheets are unlikely to be used for styling them. The problem with a canvas solution is that the entirety of the 3D data has to exist within the canvas element. If you want multiple elements in the markup to map to a single 3D window, then canvas doesn't really work. (Well, you could have them as display: none with XBL bindings that map to Javascript code which adds the object to a canvas, but at that point, you're implementing something like X3D using XBL + Javascript + canvas, which really doesn't make sense.) Having said that, there are probably use cases for declarative 3D, just like there are with declarative 2D. And for those you would use a dedicated markup language, just like you use SVG for 2D graphics. My point was that I'd like to see a CDF (not the CAD kind, but the W3C kind) that uses XHTML + X3D, or XHTML + CSS+ XBL2 + X3D. While I think it has a lot of potential, I don't know enough about how the respective standards to determine would work together. (This is partly because of my lack of knowledge of XBL2 and X3D...) 1) A Web standards version of Microsoft's Flipin' CD Button example. The markup for that is easy: input type=button ...or some such. Making it actually look like something 3D would involve CSS, XBL, and either X3D or canvas (or some other 3D solution). I already knew the HTML. I was kinda hoping to see the CSS/XBL2 part of that equation. That's the part I'm confused about. Does XBL2 have a CSS binding property like XBL 1.0? 2) An example of something similar to Quake done entirely as a web application, with a HUD. That's pure canvas, with a 3D context for the 3D, and a 2D context for the HUD. Well, that depends on whether you're using canvas or X3D. Personally, I'd like to see how X3D would be used in a compound document. I'm thinking that you could use X3D in combination with XBL to implement LOD and similar features so that 3D models can degrade gracefully into simpler models with fewer features if hardware doesn't support all the features and polygons. 3) An example of a simple 2D GUI with 3D effects as a web application. Not sure what you mean there. I mean stuff like having windows that get smaller when they're further back in the Z-order. Perhaps there's a fog effect. You could have various section elements rendered within a 3D environment, where the user looks in a specific direction or in a specific place to see the section inside a 3D environment. Stuff like that.
Re: [whatwg] Image maps: should we drop a coords=?
Ian Hickson wrote: On Mon, 11 Apr 2005, Anne van Kesteren wrote: Ian Hickson wrote: Anyone want us to keep a coords=? The reason I especially liked it was: object data=foo usemap=#foo map id=foo ul lia coords=../a ... Yup, it is indeed nice; if image maps had been designed that way from the start it would make sense. But it's not _that_ much nicer than area, which we could define as allowing: object data=foo usemap=#foo map id=foo ul liarea coords=... href=...a href=../a ... ...which isn't much worse, and has the very important benefit of actually working in IE6. This would seem to undermine your position with regards to using the a element for menu labels: | menubar id=appmenu | a href=#fileFile/a | menu Contrast this with the following: | menubar id=appmenu | menulabela href=#fileFile/a/menulabel | menu It's essentially the same scenario. In both situations, a is being used in a situation where alternative, more semantically appropriate markup already exists for the purposes of fallback. However, as illustrated in both your example and mine, a could simply be used within the same alternative markup to create fallback without overloading the semantics of a. So, with implementations of a coords= existing and gaining marketshare, why is a coords= being phased out while a href=#[menu] for use _within_ menus is being phased in?
Re: [whatwg] h1 to h6 in body
Okay, here's my two cents on the heading/section issue... The element h1 can be used in HTML4 multiple times. Therefore, it is not by default the title of a document. The most natural thing to assume is that title is the title of the document, regardless of how people might abuse it. At best, you could say that when there is only one h1 element, it might be the title. Even that is not a certainty. There are already meta values for much of the stuff that people abusively put in the title element. For example, author metadata is pretty much a standard already: | meta name=author content=Space Dog Therefore, why not just standardize it and deprecate the use of such values in title while giving title more specific semantics? Something like this: | meta name=author content=Ian Hickson | meta name=sitename content=WHATWG | meta name=publisher content=Hixie Industries The link element can be used for the stuff that requires a URL or hyperlink of some kind. As for sections, in my opinion there are two types of sections. The first is what we have now, an implied section system that is difficult to define but essentially goes from the beginning of one heading to the beginning of the next. The second type of section is one defined by markup such as section. This type should be the only type that can be styled and affect rendering. Generally, implied sections should begin at the beginning of a h# element and end at either the end of the document or at the beginning of another h# element. Allowing exceptions makes describing implied sections much more complicated. If developers need flexibility with regard to this, we can use language that says developers *should* start and end sections in such a manner rather than *must*. Importance (given by the number of the h# element) determines styling, and it implies structure, but the level of importance should not create missing sections within the document outline. If the importance level of a heading implies a missing parent section, the outline tree should first be constructed as if the implied nodes existed, then the children of missing sections should be collapsed into the position of their parents. That said, this is how I would process the sample markup: body p.../p unnamed section h1A/h1 1A (importance level 1) h2B/h2 1.1 B (importance level 2) h3C/h3 1.1.1C (importance level 3) h2D/h2 1.2 D (importance level 2) h3E/h3 1.2.1E (importance level 3) p.../pE ol E li E h3F/h3 1.2.2F (importance level 3) /liF li F h3G/h3 1.2.3G (importance level 3) /liG li G h3H/h3 1.2.4H (importance level 3) /liH /ol H p.../pH h4I/h4 1.2.4.1 I (importance level 4) h2J/h2 1.3 J (importance level 2) div J p.../p J h2K/h2 1.4 K (importance level 2) p.../p K /divK p.../pK h3L/h3 1.4.1L (importance level 3) h2M/h2 1.5 M (importance level 2) h4N/h4 1.5.1N (importance level 4) h3O/h3 1.5.2O (importance level 3) h1P/h1 2P (importance level 1) h1Q/h1 3Q (importance level 1) h2R/h2 3.1 R (importance level 2) /body This would be the outline: Document | +-- unnamed section | +-- 1 A | | | +-- 1.1 B | | | | | +-- 1.1.1 C | | | +-- 1.2 D | | | | | +-- 1.2.1 E | | | | | +-- 1.2.2 F | | | | | +-- 1.2.3 G | | | | | +-- 1.2.4 H | | | | | +-- 1.2.4.1 I | | | +-- 1.3 J | | | +-- 1.4 K | | | | | +-- 1.4.1 L | | | +-- 1.5 M | | | +-- 1.5.1 N | | | +-- 1.5.2 O | +-- 2 P | +-- 3 Q | +-- 3.1 R
Re: [whatwg] h1 to h6 in body
Ian Hickson wrote: On Mon, 4 Apr 2005, Matthew Raymond wrote: That said, this is how I would process the sample markup: body p.../p unnamed section h1A/h1 1A (importance level 1) I agree with most of what you said but the problem I have with the above is that it means almost every document will have an anonymous section at the top, and I don't think that makes sense. If p.../p were instead a list of hyperlinks to different sections of the document, should that list be part of the first section? If the paragraph inside the p element starts with I'd like to thank such-and-such for sticking by me while I wrote this..., is that part of the first section? The way I see it, if a heading starts a section, it should always be the start of a section. To do otherwise breaks consistency and may introduce semantics that are not backwards compatible in some situations. Better to use something like [Top of the document] that denotes that describes the position of the content without naming it, and also identifies that there is content before the first heading. |body | p.../p| Top (importance level 1) | h1A/h1| 1 A (importance level 1) Even in the case of: body h1.../h1 ...there's an anonymous section, because you have a whitespace text node before the element. That doesn't really work for me. Why do outline generators need to worry about text nodes at the beginning that contain only whitespace? You're talking about content that won't be rendered, so for all intents and purposes, the heading is the first item in the body. Such whitespace can simply be ignored by outliners. However, if you are suggesting that such unrendered whitespace be associated with the first section, I have no problem with that. ;)
Re: [whatwg] Introducing new elements is expensive
Ian Hickson wrote: On Sat, 12 Mar 2005, Matthew Raymond wrote: That is not the case with output in a legacy user agent. Any HTML contents will display as HTML in a legacy UA. Yet if we assume the textarea model for output, WF2 UAs will display the underlying markup as text instead of rendering it. So, right off the bat, we have a difference in how the contents of output are rendered between legacy and WF2 user agents. Elements inside output are rendered as elements, with all that that implies; there is no special parsing. The contents of output are the initial value, yet they are not parsed. /me scratches his head. Since we can't avoid a difference in rendering unless we artificially enforce a no-markup-inside-output rule, what does it hurt to simply have a |value| attribute to set the .defaultvalue directly? The two things are separate. What's the use case for value=? Well, for one, in situations where you want to use input readonly as a fallback container for a calculated value.
Re: [whatwg] [WF2] Objection to autocomplete Attribute
James Graham wrote: Lachlan Hunt wrote: Then, please at least deprecate it. If it's only being defined to help with interopable implementations, that's fine, but it's use should be discouraged as much as possible, therefore it should be deprecated. What the WHATWG spec says on this matter is irrelevant; browsers will implement whatever the banks dictate. As Hixie says, the spec only serves the purpose of documenting an accepted standard. Therefore, I really don't think it's worth any more time discussing this attribute. Actually, now that I think about it, why do we need to have a spec saying that it's not depreciated or that it should be non-trivial to deactivate if the banks are going to blackmail UAs to support it? Why support blackmail through our specifications. If banks force them to implement a specific attribute in a specific way, fine, but don't force user agents to do it that way as a matter of spec compliance.
Re: [whatwg] [html5] DI element
James Graham wrote: In general, the ability, or lack thereof, to express a given constraint in any schema language has been regarded as an unimportant consideration for Web Forms content models (and hence, by inference, is unimportant for Web Apps content models) . Therefore this isn't a good argument against using li in this way. On the other hand, if legacy UAs have some problem with li outside a HTML 4 list container, that would be a good argument against this (IMHO rather attractive) proposal. I'd be surprised if that were the case though since such a restriction would probably break real sites. I did a quick test, and using li in a dl produces a bullet on Firefox, IE and Opera, whereas di and the complete lack of a parent element did not. So, li didn't break anything, but it really didn't have the desired rendering on legacy browsers. This alone it a good argument for defeating li in this context. Plus, there's the additional fact that di is already in the XHTML 2.0 working draft, which means that it'll be easier to get di through W3C than dl/li.
Re: [whatwg] Introducing new elements is expensive
Dean Edwards wrote: Anne van Kesteren wrote: output value=barfoo/output Legacy UAs show foo where WF2 UAs show bar. This is not consistent with textarea. I think they should behave the same. output is effectively a read-only textarea. Actually, this is not the case. For textarea, if you put in HTML content inside the element, it treats the contents as PCDATA, so the user will see HTML markup inside a multiline textbox. That is not the case with output in a legacy user agent. Any HTML contents will display as HTML in a legacy UA. Yet if we assume the textarea model for output, WF2 UAs will display the underlying markup as text instead of rendering it. So, right off the bat, we have a difference in how the contents of output are rendered between legacy and WF2 user agents. Since we can't avoid a difference in rendering unless we artificially enforce a no-markup-inside-output rule, what does it hurt to simply have a |value| attribute to set the .defaultvalue directly?
Re: [whatwg] [html5] DI element
Anne van Kesteren wrote: Matthew Raymond wrote: Cool. I hadn't really thought about this situation. Let's see if I can fit it into my previous section/h proposal: Isn't that just the proposal from XHTML 2.0? Also, that is not backwards compatible. It's similar, but I've elaborated on it significantly. My model allows for both h and h# elements. The example I gave was simple a WA1-only example. Here's how it would work with h# elements: | section | h1HEADING1/h1 | pThis is a paragraph related to heading 1./p | pThis is a paragraph related to heading 1./p | section | h2HEADING 1.1/h2 | pThis is a paragraph related to heading 1.1./p | pThis is a paragraph related to heading 1.1./p | /section | pThis is a paragraph related to heading 1./p | pThis is a paragraph related to heading 1./p | /section In my model, h automatically determines importance based on the nesting of its parent section element. So if you use h for HEADING1, h is semantically the same as h1. The same is true for HEADING 1.1: h is the same as h2. I support including both SECTION and DI. But if SECTION isn't required, I cannot see why DI should be required. Apples and oranges. For instance, why couldn't unordered or ordered lists within a definition list be used? Huh? DI is intended for grouping DT and DD elements, not for grouping DD elements. I was reworking a previously posted example that only included multiple dd elements. Don't assume that I wasn't applying the same logic to dt simply because I didn't give an example of such. Also, the definition of CSS is not an ordered list containing two separate items. The definitions are separate. Looking over the HTML 4.01 specification, it does appear that dt and dd are defined as only containing a single term or definition, so you may have a point. The di element may be necessary for grouping multiple terms and definitions.
