[whatwg] Please consider allowing del datetime and ins datetime attribute to accept only a date

In short: the datetime attribute (on both del and ins elements) should permit just a date value, in addition to permitting explicit dates with times. Reasoning/advantages provided on the wiki: http://wiki.whatwg.org/wiki/Del_element I encourage fellow web authors to add opinions/comments to

[whatwg] Please consider adding timeref attribute to del and ins elements

Summary: add a new timeref attribute (of type idref) to del and ins elements 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. Advantages: 1. encourage more visible data (dates in visible

[whatwg] Please consider simplifying authoring guidance for the img alt attribute

With acknowledgement of existing issues (e.g. http://www.w3.org/html/wg/tracker/issues/80 ) on the topic: Summary: Please consider simplifying authoring guidance for the img alt attribute, such as dropping the document is an e-mail and meta generator cases. More details provided on the wiki:

[whatwg] Please consider dropping the sandbox attribute from the iframe element

Summary: The new 'sandbox' feature on iframe should be considered for removal. It needs a security review, it will be a lot of work to implement properly, and may not actually solve the problem it is intending to solve. More details here: http://wiki.whatwg.org/wiki/Iframe_Sandbox I encourage

Re: [whatwg] Please consider dropping the sandbox attribute from the iframe element

On Mon, Aug 2, 2010 at 6:41 AM, Maciej Stachowiak m...@apple.com wrote: On Aug 1, 2010, at 6:59 PM, Tantek Çelik wrote: Summary: The new 'sandbox' feature on iframe should be considered for removal. It needs a security review, it will be a lot of work to implement properly, and may

[whatwg] Please consider making summary more generic/flexible (or renaming)

Summary: the new summary element is very generic sounding but has a very special purpose (only allowed inside details). It would be helpful if we made it more generic, in particular allow use of summary inside article body (and perhaps section) to provide general summary text semantics (e.g. this

[whatwg] Please consider allowing the time element to accept coarser granularity dates

Summary: the new time element is very useful for absolute dates and times, but omits several useful granularity levels, in particular for dates. The following additional date granularities would be useful, and are fairly straightforward to incorporate into the spec (and implementations): * year

[whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day

Summary: the 6 new datetime input types are quite useful for a variety of use-cases but could use 2 more that fit in with the current set. In addition to current new absolute types of date, week, month, it makes sense to add type=year as well for choosing a year value. And in addition to the

Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day

as are (would be) for input type=week, e.g. birthdays, new holidays. Thanks for the questions, I've added them to a new FAQ section on the proposal: http://wiki.whatwg.org/wiki/Input_element#new_datetime_input_FAQ Tantek [1] http://www.longnow.org/ On 09/08/2010, at 9:20 AM, Tantek Çelik wrote

[whatwg] Please consider impedance matching time and datetime input types

Summary: HTML5 provides mechanisms for both semantically inputting datetime values (via the 6 new datetime input types), and semantically outputting datetime values (via the new time element). However, the types/granularities of dates and times that are supported do not match up on input vs

[whatwg] Please consider time syntax processing improvements for better DRY and thus more accurate data over time

We know from experience with past methods of duplicated invisible (meta)data, and more recently, development/use/experience with visible microformats, that when we are able to re-use the visible data, published *once*, by humans for humans, we get more accurate data over time, than when we have at

[whatwg] Minor editorial fix: Section 4.6.9 The time element - first example needs update

The first markup example in section 4.6.9 needs updating: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element Current Example and text: === snip === div class=vevent a class=url

[whatwg] Please (re)consider explicitly allowing marking up speaker names with cite (new information)

Summary: there has been longstanding discussion about the use (or not) of cite to markup names of speakers. From original intent of cite, to references to the Chicago Manual of Style, to the practicality of it just being an alias for i. I (and others) have done a bunch of research and

[whatwg] proposal: extend time to markup durations

Some in the microformats community have been making good use of the time element, e.g. for publishing hCalendar, and implementing consuming/converting hCalendar [1] with good success. It would be great if the time element could support expressing durations as well for the use cases as needed by

Re: [whatwg] a rel=attachment

2011/7/14 Darin Fisher da...@chromium.org: On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard gl...@zewt.org wrote: 2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word

Re: [whatwg] The blockquote element spec vs common quoting practices

In agreement with Jeremy, I too have found the blockquote/q cite attribute to be nearly as ignored as the longdesc attribute, despite having conducted talks and written tutorials about how to use the cite= attribute (makes me think that the non-visible-effect-URL attributes on elements should be

Re: [whatwg] a rel=attachment

On Thu, Jul 14, 2011 at 13:46, Darin Fisher da...@chromium.org wrote: On Thu, Jul 14, 2011 at 1:32 PM, Tantek Çelik tan...@cs.stanford.edu wrote: 2011/7/14 Darin Fisher da...@chromium.org: On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard gl...@zewt.org wrote: 2011/7/14 Ian Fette

Re: [whatwg] Styling details

On Thu, Jul 14, 2011 at 15:21, Ian Hickson i...@hixie.ch wrote: (This isn't the final reply on this thread, but I thought I should give a heads-up as to the general direction I am expecting us to go in here.) On Wed, 6 Apr 2011, Lachlan Hunt wrote:   We've been experimenting with the

Re: [whatwg] a rel=attachment

Agreed with Glenn, narrowing the semantic solves this problem neatly: * filename= attribute - what to name the file if saved by the user (by whatever means) * existing rel=enclosure spec - download the link when clicked/activated. So the author can choose to do one, or the other, or both.

Re: [whatwg] a rel=attachment

...@google.com Subject: Re: [whatwg] a rel=attachment On Fri, Jul 15, 2011 at 5:38 PM, Tantek Çelik tan...@cs.stanford.eduwrote: * existing rel=enclosure spec - download the link when clicked/activated. I object to rel=enclosure purely on naming grounds. It is completely unintuitive. I don't

Re: [whatwg] adding microdata to basic links

On Wed, Aug 24, 2011 at 10:22, Stéphane Corlosquet scorlosq...@gmail.com wrote: On Wed, Aug 24, 2011 at 1:18 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Wed, Aug 24, 2011 at 10:02 AM, Stéphane Corlosquet scorlosq...@gmail.com wrote: Starting from a basic markup like this: [[[ This

Re: [whatwg] Question: rel=help

Schalk, Javascript-only help text (tooltip or otherwise) or any other content intended for human consumption is a really bad idea for all the usual reasons (#a11y, mobile, search etc.) Consider adjusting your content design to incorporate the help text instead (perhaps with either the

Re: [whatwg] Question: rel=help

On Thu, Sep 29, 2011 at 11:12, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 29.9.2011 20:50, Tantek Çelik wrote: Javascript-only help text (tooltip or otherwise) or any other content intended for human consumption is a really bad idea for all the usual reasons (#a11y, mobile, search etc

Re: [whatwg] Fullscreen

Hi Anne, Fullscreen is currently #2 in my queue after getting another LCWD of CSS3-UI out. I've been incrementally editing on the wiki page you mentioned until it's my primary focus. Feel free to make edits to the wiki if there are particular aspects you want to improve or raise as issues.

Re: [whatwg] Geographic hyperlinks

See RFC 5870[1] for a proposed standard geo URI scheme for geo: hyperlinks. - Tantek [1] http://tools.ietf.org/html/rfc5870 On Mon, Oct 10, 2011 at 10:27, Matthew Slyman wha...@aaabit.com wrote: http://forums.whatwg.org/bb3/viewtopic.php?f=3t=4725 [Topic has been on forum for 2 weeks without

[whatwg] should we add beforeload/afterload events to the web platform?

WebKit supports a 'beforeload' event [1] which is supported in shipping Safari and Chrome[2] and apparently has (enabled) the real-world use-cases of: 1. Performance. Reducing bandwidth use / HTTP requests, e.g. AdBlock extension[2] 2. Clientside transformations, e.g. Mobify[3] As might be

Re: [whatwg] A plea to Hixie to adopt main

This was meant to follow-up to Henri's message[1]: [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/038219.html but for some reason that didn't make it to my archives so I'm replying to the latest message on this thread that did. tl;dr: Having previously opposed the

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

On Fri, Dec 2, 2016 at 9:07 AM, Michael A. Peters wrote: > On 12/02/2016 08:47 AM, Boris Zbarsky wrote: >> >> On 12/2/16 11:34 AM, Michael A. Peters wrote: >>> >>> It seems that CSP behavior has radically changed since the last time I >>> looked at it >> >> >> I can't