Re: [whatwg] Toggling Attributes
Christoph Päper wrote: Ian Hickson (2009-02-13): There are three of these attributes so far: autocomplete = on/off contenteditable = true/false draggable = true/false It would be nice, actually, from an author perspective at least, if all of these worked for all applicable attributes: foo bar foo bar=bar foo bar=on foo bar=true foo bar=1* foo* foo bar=* foo bar=off foo bar=false foo bar=0* * I am not completely sure about the ones marked with an asterisk, because digits may not be necessary and the default or inherited state may be 'enabled'. Also take into account what should happen when other values than defined appear: foo bar=someothervalue Regards, Rikkert Koppes
[whatwg] content models clarity
The content models [1] section is pretty clear, however, whenever one wants to know which elements fall into a specific content model, one has to look at the categories definition of each element. A (possibly non normative) overview would be helpful. I understand it is repeating information, hence possibly leading to conflicts when not paying attention while editing, but I think it would clarify a lot. Consider a similar overview to the one found in [2] listing the applicable attributes to various input types. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#content-models [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-input-element Regards, Rikkert Koppes
[whatwg] section element example
The example presented at the section element definition [1]. The given markup could be ok, however, with a look at the actual contents (a nice essay about apples), the h1 elements found in the section elements should actually be h2 elements, giving rise to the folowing document structure: Apples - Red Delicious - Granny Smith [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-section-element Cheers, Rikkert Koppes
[whatwg] Example / pattern document for authors
Dear all, Would it be a nice idea to create a (non normative) example document for authors, containing at least the examples from the spec, amended with more elaborate examples of complete structures and real life samples? If so, would the whatwg wiki be a good start to host this, with the intend to create a document accompanying the specification? If the answer is yes, I would be happy to create a start. Regards, Rikkert Koppes
[whatwg] Address example to be changed to lowercase
In contrast to the rest of the spec, the address element example is shown in uppercase. For clarity, this would better be put in lowercase Regards, Rikkert Koppes
[whatwg] dl definition issue
At the dl element definition [1] a) The order of the list of groups, and of the names and values within each group, may be significant. b) The |dl http://www.whatwg.org/specs/web-apps/current-work/#the-dl-element| element is inappropriate for marking up dialogue, since dialogue is ordered (each speaker/line pair comes after the next). It occurs to me that the argument, put forward in b), does not hold, since a). Hence, the argument needs to be rephrased or otherwise adjusted. For example: The |dl http://www.whatwg.org/specs/web-apps/current-work/#the-dl-element| element is inappropriate for marking up dialogue, since dialog is a more appropriate semantic element. For an example of how to mark up dialogue, see the |dialog http://www.whatwg.org/specs/web-apps/current-work/#the-dialog-element| element. [1] http://www.whatwg.org/specs/web-apps/current-work/#the-dl-element Regards, Rikkert Koppes
[whatwg] form markup
There are various ways to forms are beining marked up, to name a few 1. use a table, put labels and inputs in cells 2. use a dl, put labels in dt, put inputs in dd 3. use p elements to surround label and input pairs 4. use an ol element, let li surround label and input pairs 5. use an ul element, let li surround label and input pairs Is there any preferred method? Regards, Rikkert Koppes
Re: [whatwg] form markup
Well, suppose a personal information fillout form, i.e.: first name, last name, initials, street, number, postal code, city fields. Things that belong to a set (personal information), which is usually an argument to use a list (being ol, ul or dl) for markup. While I value your personal preferences, is there any whatwg consensus? Cheers, Rikkert Koppes Ian Hickson wrote: On Tue, 24 Feb 2009, Rikkert Koppes wrote: There are various ways to forms are beining marked up, to name a few 1. use a table, put labels and inputs in cells 2. use a dl, put labels in dt, put inputs in dd 3. use p elements to surround label and input pairs 4. use an ol element, let li surround label and input pairs 5. use an ul element, let li surround label and input pairs Is there any preferred method? It's hard to tell without more details on what kind of form you have in mind. For most forms, I tend to prefer p elements personally.
Re: [whatwg] strong and em difference not clear
Maybe the terms global emphasis and local emphasis could help. In printed media bold and italic print behave differently in the sense that bold words grab attention directly, since it is based on lightness difference, for which the entire retina is highly sensitive, whereas italic words only grab attention when looked at, since it is based on differences in orientation, for which the fovea is much more sensitive. Hence, bold words have meaning with regard to the entire document and italic words have meaning just for the sentence read at the moment. Although the em and strong elements are deliberately detached from their appearance, the emerging semantics (global and local emphasis) still make sense. Note that from a perception point of view, global emphasis may also be achieved by other means for which the entire retina is sensitive. Difference in color for example. Local emphasis may also be achieved by changing font. [1,2] [1] http://en.wikipedia.org/wiki/Emphasis_(typography) [2] http://www.cs.tut.fi/~jkorpela/html/em.html Regards, Rikkert Koppes Peter Michaux wrote: On Tue, Feb 17, 2009 at 12:45 PM, Edward O'Connor hob...@gmail.com wrote: The HTML 5 spec doesn't give clear guidance on the choice between strong and em tags. The spec distinguishes between importance (strong) and emphasis (em) like so: The placement of emphasis changes the meaning of the sentence. The element thus forms an integral part of the content. and Changing the importance of a piece of text with the strong element does not change the meaning of the sentence. So, basically, putting em around different words in a sentence changes the sentence's meaning, whereas moving strong around in the same way doesn't alter the meaning of the text. Do you think that's sufficiently clear? I suppose it is reasonably clear with these two sentences. I should have attributed more attention to them. Thank you, Peter
Re: [whatwg] False orthogonal nature :read-only and :disabled in WF2
Either I am rather confused or there are some misunderstandings still. Some observations: Ian Hickson wrote: Having them be orthogonal is far more useful to authors. For example, imagine the following stylesheet: And I've made HTML5 say that :read-write doesn't apply to disabled controls. (1) If :read-write does not apply to disabled controls, :read-only does (since it applies to all other html elements - meaning they are mutually exclusive). Hence :disabled implies :read-only (not vice versa for the record) and hence :disabled and :read-only are not orthogonal. The spec now says :read-write does not apply to input elements that do NOT have the readonly attribute specified AND that are NOT disabled, or in other words (by mutual exclusivity), :read-only applies to input elements that have the readonly attribute specified OR are disabled. Grtz, Rikkert Koppes
Re: [whatwg] [wf2] :read-write pseudoclass description issue
I see your point, to go for another route, maybe you'd just edit the source of the problem (the note), remove it and include a text similar to the remark about the disabled attribute. I.e: --- When an input element is disabled, it is immutable. When an input element is readonly, it is immutable. --- However, there is no readonly concept defined (maybe this will clarify more, but actually I think it's likely to complicate things even more). Hence, another suggestion could be: --- An input element to which the readonly attribute applies and has that attribute specified, is immutable. --- Cheers, Rikkert Koppes Ian Hickson wrote: On Wed, 11 Feb 2009, Rikkert Koppes wrote: At [1] I'd suggest changing the second sentence to When specified and applicable, the element is immutable. [1]: http://www.whatwg.org/specs/web-apps/current-work/#attr-input-readonly Yeah, I keep thinking of doing something like that. The reason I haven't yet is that I don't want to go down the route of people seeing that and thinking that that means that other things in that section might apply even when they don't (the intro to that section explicitly says that nothing there applies if the attributes aren't applicable).
Re: [whatwg] Reverse ordered lists
I am not quite sure whether this should be covered by html at all. List numbering should be a matter of CSS I think. Using an ol only means that it's items are ordered, not in what way. There is a difference between ordinal value (which might be specified by the value attribute of an li element) and things like, say, ranking, score and numbering Regards, Rikkert Koppes Siemova wrote: Daniel Glazman wrote: Usually, the answer is because nobody uses it anyway Perhaps so, but I certainly wouldn't say nobody wants to use reverse-ordered lists. I've seen plenty of them across the web (whether non-HTML or hacked via CSS, tables, etc.), and more than a few complaints that there's no easy, standardized way to make them. Besides, designing and implementing such a feature ought to be so easy for W3C and UA's that the (admittedly minor) benefit would be entirely worth the small trouble. I'd never claim my proposal to be earth-shattering, but it's not much less worthwhile than the start attribute. They're both useful in certain infrequent-but-not-improbable situations, and stay out of the way when not needed. :) - Jason (Siemova)
Re: [whatwg] [wf2] repetition model addition step 14 issue
Note that this is also an issue in Opera's current implementation test case: http://www.rikkertkoppes.com/other/wf2-repetition-model/ note the legend element ending up halfway the fieldset. It occurs to that this is unwanted bahaviour, it follows directly from the current wd though Regards, Rikkert Koppes Rikkert Koppes wrote: Related is the movement of repetition blocks, section 3.6.3 step 3: http://www.whatwg.org/specs/web-forms/current-work/#movement --- # If distance is negative: while distance is not zero and target's |previousSibling| is defined and is not a repetition template http://www.whatwg.org/specs/web-forms/current-work/#repetition2, set target to this |previousSibling| and, if it is a repetition block http://www.whatwg.org/specs/web-forms/current-work/#repetition3, increase distance by one (make it less negative by one). --- blocks might move above previous siblings that are not repetition blocks (picture a legend element). Regards, Rikkert Koppes Rikkert Koppes schreef: the addition sequence, step 14 states (http://www.whatwg.org/specs/web-forms/current-work/#addition): --- If the first argument to the method was null, then the template once again crawls through its previous siblings, this time stopping at the first node (possibly the template itself) whose previous sibling is a repetition block (regardless of what that block's template is) or the first node that has no previous sibling, whichever comes first. The new element is the inserted into the parent of the template, immediately before that node. Mutation events are fired if appropriate. --- Furthermore, as I interpret correctly, this is also the case at initialisation, i.e. the addRepetitionBlock() method is invoked with null as it's argument (http://www.whatwg.org/specs/web-forms/current-work/#initial). (not quite sure whether this is indeed correct interpreted, see further) --- For each element that has a |repeat http://www.whatwg.org/specs/web-forms/current-work/#repeat| attribute with the literal value |template http://www.whatwg.org/specs/web-forms/current-work/#template|, the UA must invoke the template's replication behaviour as many times as the |repeat-start http://www.whatwg.org/specs/web-forms/current-work/#repeat-start| attribute on the same element specifies (just once, if the attribute is missing or has an invalid value).[...] (Invoking the template's replication behaviour means calling its |addRepetitionBlock() http://www.whatwg.org/specs/web-forms/current-work/#addrepetitionblock| method). --- If this is the case, at initialisation, when there are no repetition blocks, the first block is added as the very first child of the template's parent, which is not necessarily before the template. This doesn't seems to be desired very often. Picture a fieldset with a legend where the first replicated block ends up before the legend. Should the initial replication behaviour maybe call the addRepetitionBlock with the template's previous sibling as argument? Regards, Rikkert Koppes
[whatwg] [wf2] repetition model addition step 14 issue
the addition sequence, step 14 states (http://www.whatwg.org/specs/web-forms/current-work/#addition): --- If the first argument to the method was null, then the template once again crawls through its previous siblings, this time stopping at the first node (possibly the template itself) whose previous sibling is a repetition block (regardless of what that block's template is) or the first node that has no previous sibling, whichever comes first. The new element is the inserted into the parent of the template, immediately before that node. Mutation events are fired if appropriate. --- Furthermore, as I interpret correctly, this is also the case at initialisation, i.e. the addRepetitionBlock() method is invoked with null as it's argument (http://www.whatwg.org/specs/web-forms/current-work/#initial). (not quite sure whether this is indeed correct interpreted, see further) --- For each element that has a |repeat http://www.whatwg.org/specs/web-forms/current-work/#repeat| attribute with the literal value |template http://www.whatwg.org/specs/web-forms/current-work/#template|, the UA must invoke the template's replication behaviour as many times as the |repeat-start http://www.whatwg.org/specs/web-forms/current-work/#repeat-start| attribute on the same element specifies (just once, if the attribute is missing or has an invalid value).[...] (Invoking the template's replication behaviour means calling its |addRepetitionBlock() http://www.whatwg.org/specs/web-forms/current-work/#addrepetitionblock| method). --- If this is the case, at initialisation, when there are no repetition blocks, the first block is added as the very first child of the template's parent, which is not necessarily before the template. This doesn't seems to be desired very often. Picture a fieldset with a legend where the first replicated block ends up before the legend. Should the initial replication behaviour maybe call the addRepetitionBlock with the template's previous sibling as argument? Regards, Rikkert Koppes
Re: [whatwg] [wf2] repetition model addition step 14 issue
Related is the movement of repetition blocks, section 3.6.3 step 3: http://www.whatwg.org/specs/web-forms/current-work/#movement --- # If distance is negative: while distance is not zero and target's |previousSibling| is defined and is not a repetition template http://www.whatwg.org/specs/web-forms/current-work/#repetition2, set target to this |previousSibling| and, if it is a repetition block http://www.whatwg.org/specs/web-forms/current-work/#repetition3, increase distance by one (make it less negative by one). --- blocks might move above previous siblings that are not repetition blocks (picture a legend element). Regards, Rikkert Koppes Rikkert Koppes schreef: the addition sequence, step 14 states (http://www.whatwg.org/specs/web-forms/current-work/#addition): --- If the first argument to the method was null, then the template once again crawls through its previous siblings, this time stopping at the first node (possibly the template itself) whose previous sibling is a repetition block (regardless of what that block's template is) or the first node that has no previous sibling, whichever comes first. The new element is the inserted into the parent of the template, immediately before that node. Mutation events are fired if appropriate. --- Furthermore, as I interpret correctly, this is also the case at initialisation, i.e. the addRepetitionBlock() method is invoked with null as it's argument (http://www.whatwg.org/specs/web-forms/current-work/#initial). (not quite sure whether this is indeed correct interpreted, see further) --- For each element that has a |repeat http://www.whatwg.org/specs/web-forms/current-work/#repeat| attribute with the literal value |template http://www.whatwg.org/specs/web-forms/current-work/#template|, the UA must invoke the template's replication behaviour as many times as the |repeat-start http://www.whatwg.org/specs/web-forms/current-work/#repeat-start| attribute on the same element specifies (just once, if the attribute is missing or has an invalid value).[...] (Invoking the template's replication behaviour means calling its |addRepetitionBlock() http://www.whatwg.org/specs/web-forms/current-work/#addrepetitionblock| method). --- If this is the case, at initialisation, when there are no repetition blocks, the first block is added as the very first child of the template's parent, which is not necessarily before the template. This doesn't seems to be desired very often. Picture a fieldset with a legend where the first replicated block ends up before the legend. Should the initial replication behaviour maybe call the addRepetitionBlock with the template's previous sibling as argument? Regards, Rikkert Koppes
[whatwg] [wf2] repetitionTemplate and repetitionBlocks attributes in addition/removal steps
Nowhere in the addition and removal steps, the setting / clearing of repetitionTemplate and repetitionBlocks attributes is listed (3.6.2 and 3.6.3) suggestion: In the case of addition, insert a step after step 12 which tells to equip the clone with a repetitionTemplate DOM attribute and add the clone to the repetitionBlocks collection of the template In the case of removal, it is unclear whether these attributes have to be adjusted. It might be the case that the removeRepetitionBlock returns the removed block (as is the case with removeChild), in that case, it seems logical to keep the cross references alive Regards, Rikkert Koppes
Re: [whatwg] (no subject)
As I said, I am working on a wf2 imnplementation library. I am aware of the ongoing project (http://code.google.com/p/webforms2/), but it was more fun doing this on my own. I implemented a whole lot of the spec, including repetition model. Everything is not quite mature yet, but I would like to share it with the world anyway. http://www.rikkertkoppes.com/thoughts/wf2/ Regards, Rikkert Koppes Ian Hickson schreef: On Tue, 28 Aug 2007, Rikkert Koppes wrote: I am currently implementing a js library to make wf2 functionality available to legacy browsers (I know google is doing this too). Some things that came to mind are: - when validity flags are not set, should they equal null or false? False. Is the spec not clear on this? - this might have been proposed before: consider a reset() method for form controls and fieldsets You can already do this reasonably easily; I'm not sure an explicit API is really that useful. I'll bear it in mind though. - in this light: consider a clearable or resettable boolean attribute for inputs, which might display a clear button in the field, as seen in for example the mail filter in thunderbird. This should reset the control to the default value, ie calling the above reset() method, example formatting: +--- legend [x] ---+ | | |+--+ | || [x]| | |+--+ | +--+ which shows a clear button on a fieldset and input field. Note that Opera's date related fields also have an none button, which might be equivalent of the above That's just a UI detail. Nothing is stopping UA implementors from including this kind of UI today. - are negative years allowed (B.C.)? the datetime description tells me four or more digits (0 to 9) representing the year which implies no. use case: hystory questionary No, negative years aren't allowed. As has been pointed out by others, the date control isn't really that useful as defined today for non-contemporary dates. The use case is primarily e-commerce. Historical cases are far more complex, rarer, and probably need custom UI, and thus don't really fall in our 80% target. Let us know if there's anything else we can do to help with your implementation! Also, note that there's an implementors mailing list if you want to discuss implementation-specific details: http://www.whatwg.org/mailing-list#imps HTH,
[whatwg] [wf2] :read-write pseudoclass description issue
http://www.whatwg.org/specs/web-forms/current-work/#relation :read-only Matches form control elements that have the |readonly http://www.whatwg.org/specs/web-forms/current-work/#readonly| attribute set, and to which the |readonly http://www.whatwg.org/specs/web-forms/current-work/#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 http://www.whatwg.org/specs/web-forms/current-work/#datalist|, |option|, |optgroup|, and |fieldset| elements). :read-write Matches form control elements that do not have the |readonly http://www.whatwg.org/specs/web-forms/current-work/#readonly| attribute set (including |password http://www.whatwg.org/specs/web-forms/current-work/#password| controls, although technically they should be called writeonly), or to which the attribute doesn't apply (such as radio buttons). A disabled control can still match this pseudo-class; the states are orthogonal. I believe the term orthogonal is incorrect here. Following (the rest of) the text, it occurs to me these pseusoclasses are opposite (mutually exclusive), while orthogonal means, they can both apply, independent of eachother. Proposal: exchange orthogonal with mutually exclusive, unless I completely misunderstood Regards, Rikkert Koppes
Re: [whatwg] [wf2] :read-write pseudoclass description issue
Ah Let me rephrase the proposal: replace A disabled control can still match this pseudo-class; the states are orthogonal. with A disabled control can still match this pseudo-class; the disabled and read-write states are orthogonal. current description could fool more people :) Regards, Rikkert Koppes Anne van Kesteren schreef: Quoting Rikkert Koppes [EMAIL PROTECTED]: [...] A disabled control can still match this pseudo-class; the states are orthogonal. I believe the term orthogonal is incorrect here. :read-write is orthogonal to :disabled. That's correct.
[whatwg] (no subject)
I am currently implementing a js library to make wf2 functionality available to legacy browsers (I know google is doing this too). Some things that came to mind are: - when validity flags are not set, should they equal null or false? - this might have been proposed before: consider a reset() method for form controls and fieldsets - in this light: consider a clearable or resettable boolean attribute for inputs, which might display a clear button in the field, as seen in for example the mail filter in thunderbird. This should reset the control to the default value, ie calling the above reset() method, example formatting: +--- legend [x] ---+ | | |+--+ | || [x]| | |+--+ | +--+ which shows a clear button on a fieldset and input field. Note that Opera's date related fields also have an none button, which might be equivalent of the above - are negative years allowed (B.C.)? the datetime description tells me four or more digits (0 to 9) representing the year which implies no. use case: hystory questionary Regards, Rikkert Koppes
