A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
Del element: Difference between revisions
m (→timeref: t) |
(→datetime attribute changes: link to datetime attribute in w3c dev draft, add related validator.nu bug) |
||
Line 29: | Line 29: | ||
ACCEPTED 2010-08-24: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028113.html | ACCEPTED 2010-08-24: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028113.html | ||
The <code>del</code> element has a <code>datetime</code> attribute that requires an explicit date and time. | Related: [http://bugzilla.validator.nu/show_bug.cgi?id=763 Validator.nu Bug 763] | ||
The <code>del</code> element has a <code>[http://dev.w3.org/html5/spec/edits.html#attr-mod-datetime datetime]</code> attribute that requires an explicit date and time. | |||
Summary: the <code>datetime</code> attribute (on both del and ins elements) should permit just a date value, in addition to permitting explicit dates with times. | Summary: the <code>datetime</code> attribute (on both del and ins elements) should permit just a date value, in addition to permitting explicit dates with times. |
Revision as of 09:19, 31 August 2010
del element proposals
Research, data, use cases, issues, and enhancements related to the HTML5 del
element.
datetime attribute
timeref
Summary: add a new timeref
attribute (of type idref
) that can be used to reference the id
of a local to document <time>
element which is then used as the datetime
value of when the deletion or insertion occurred.
Example:
<p>Here is a paragraph of text with some important information. <del timeref="change1">That was rushed out hurriedly.</del> <ins timeref="change1">Update <time id="change1">2010-07-29</time>: Here is some new information</ins> </p>
Advantages:
- visible metadata! the date of the change can be shown visibly (as many real world examples do (citations needed), rather than invisibly in a hidden datetime attribute, which encourages higher fidelity metadata.
- DRY! (don't repeat yourself). compare the previous example to the timeref one - the timeref example provides the date only once instead of duplicating it. Whenever multiple del/ins edits occur at the same date/time they can all reference a single
<time>
element.
Opinions / discussion:
- +1 Tantek Çelik
- +1 EdwardOConnor - This would be great for blog post authoring.
del element resolved proposals
datetime attribute changes
dates without times
ACCEPTED 2010-08-24: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028113.html
Related: Validator.nu Bug 763
The del
element has a datetime
attribute that requires an explicit date and time.
Summary: the datetime
attribute (on both del and ins elements) should permit just a date value, in addition to permitting explicit dates with times.
- ISO8601 syntax
- YYYY-MM-DD
Currently the datetime
attribute requires both a date and a time.
On the other hand, the time element's datetime attribute allows just a date.
Allowing just a date has the following advantages:
- easier for hand-authoring (per the preferring authors principle of the HTML5 design principles). Authors can more easily add ins/del elements with explicit datetime attributes if they are permitted to specify only the date (they might not know or care about the precise time), e.g. in blog posts that are updated by the author.
- avoids artificial precision. Forcing an explicit date and time forces authors to enter artificial precision (e.g. YYYY-MM-DDT00:00:00Z instead of YYYY-MM-DD). Allowing just dates permits authors to convey that a del/ins occurred on a certain day, and that the precise time is unknown or irrelevant.
Example:
<p>Here is a paragraph of text with some important information. <del datetime="2010-07-29">That was rushed out hurriedly.</del> <ins datetime="2010-07-29">Update: here is some new information</ins> </p>
Opinions / discussion:
- +1 Tantek Çelik - this happens to me often when I have blog-like or other essay content that I update by hand. Since I typically do updates to any particular content about once a day, day-level granularity is sufficient. Picking an arbitrary time seems like being forced to provide "fake" metadata which I don't want to do.
- +1 EdwardOConnor - I have the same sort of experience as Tantek in this case; confabulating precision where none exists feels quite wrong.