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

[Tantek Çelik]

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 speak to when you last looked at it, but the current state
>> shipping in browsers is, as far as I know, no different from what
>> browsers shipped initially for purposes of this discussion.
>>
>>> At least historically, the on* attributes were not allowed, the style
>>> attributes were not allowed, and any script nodes in the body were not
>>> allowed.
>>
>>
>> If you specify script-src and style-src and don't include
>> 'unsafe-inline', sure.
>>
>>> If CSP now allows them by default then I am not very happy about that
>>
>>
>> CSP allows the things you don't issue directives for.  If you don't
>> issue any script-src directives (or default-src directives), then there
>> won't be any limitations on scripts.
>>
>> -Boris
>
>
> Last time I read the specification, unsafe-inline didn't exist. Last time I
> glanced at the site, unsafe-inline existed but was not supported by all
> browsers and required a declared hash to work.

I have been using unsafe-inline on both style and script directives in
the CSP live on my site tantek.com (home page, permalinks) for over a
year.

I have seen no problems with Firefox / Chrome / Safari, and have not
gotten any reports of problems from Edge users either.

I documented the CSP directive I'm using here: https://indieweb.org/CSP#Tantek

If you know of any specific browsers where it is "not supported", let
me know, because I have received zero such reports.

Thanks,

Tantek

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

[Tantek Çelik]

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 addition of a main element, I've
been convinced by the arguments (and counter-counter-arguments) and
evidence presented[1] that it's worth adding main to HTML.


I'm a strong advocate of being conservative of adding new elements to
HTML. Every element we add has a cost (in maintenance, learning etc.)
and perhaps increasingly so. That's the high bar that has been
referenced that has to be met - a new element must provide advantages
outweighing the cost to all of us of adding a new element. In
particular I am thinking of the cost to authors/developers of
continuing to grow HTML and its complexity.

aside
If anything I think I've grown more conservative regarding new
elements in this regard based on experience teaching authors. I used
to support hgroup, and though while I personally find it useful in
content, I no longer find its addition useful enough for authors in
general to overcome the confusion it adds. Similarly with section
(which appears to be turning into an alias for div). IMO the outline
algorithm is dead and we could simplify HTML by dropping these two.
/aside

There has been a lot of reference to previous threads (on this list,
other lists, etc.) and at some point it becomes useless to say go
search the mail archives because no one has time follow all the
meandering threads.

I've written up a wiki page documenting what I believe to be
sufficient arguments to add the main element, along with arguments
against that I've heard and rebuttals, as well as counter-proposals
made along with flaws in counter-proposals:

http://wiki.whatwg.org/wiki/Main_element

Contributions/corrections/citations welcome, both for *and* against main.

From discussions I've seen there appears to be a growing implementer
consensus that adding a main element helps more than it hurts and
thus I expect to see it happen.

However, I still think adding main is fully supported on principle
(rather than just on browser-implementation-Hixie-veto-override) and
thus I'm interested in capturing that on the wiki page so that
hopefully we can learn from this analysis about adding a new element
and use those lessons when considering new elements in the future.

Thanks,

Tantek

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

[Tantek Çelik]

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 expected, there is at least one use-case for a
complementary 'afterload' event:

1. Downloadable fonts - people who want to use custom fonts for
drawing in the canvas element need to know when a font has loaded.
'afterload' seems like a good way to know that, since it happens as a
side effect of actually using it and fonts don't have an explicit load
API like images do.[4]


Safari and Chrome have already shipped 'beforeload', and Mozilla is
strongly considering implementing 'beforeload' and 'afterload'.[4]

Should 'beforeload'/'afterload' be explicitly specified and added to
the web platform?

Rather than attempt to provide a specific detailed design at this
point, I'd prefer to ask for the list's consideration/discussion, and
leave detailed specification of the two events to the editor.

Thanks,

Tantek

[1] 
http://developer.apple.com/library/safari/documentation/Tools/Conceptual/SafariExtensionGuide/MessagesandProxies/MessagesandProxies.html
[2] http://google-chrome-browser.com/tags/beforeload
[3] http://mobify.com/static/talks/client-side-transformations.html#27
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=715695#c9

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

Re: [whatwg] Geographic hyperlinks

[Tantek Çelik]

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 reply. Now posting to mailing
 list.]
 --

 Hyperlinks for geographic coordinates are a mess. Designers of web
 applications are being forced to design their own solutions to make
 geographic links more user-friendly...

 http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates

 http://toolserver.org/~geohack/geohack.php?pagename=Londonparams=51_30_26_N_0_7_39_W_type:city(7825200)_region:GB

 There's a relatively simple solution to all of this that could easily be
 upgraded over time. We already have mailto:; hyperlinks, for example, that
 accept certain fields and map those to certain parameters within a
 user-definable (or system-specific) mail client application.

 The same could be done for geographic data. The user might install certain
 geographic information systems on their viewing device, specify their
 favourite for geo: links, and then when they follow a hyperlink with
 geographic content, any relevant information fields present might be
 transferred over to the geographic information system (GIS) as coordinates.

 I suggest for the HTML standards people to simply talk to Wikipedia or
 Google and copy their system, as a starting-point for discussion at least.
 Maybe their format could be tidied up slightly, but generally I think
 they've done a good job and that their work should be adopted as a standard,
 so that you don't end up seeing pages with dozens of hyperlinks (one for
 each GIS) as we do on Wikipedia.

 --
 Matthew Slyman, M.A. Computer Science (Camb)







-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

Re: [whatwg] Fullscreen

[Tantek Çelik]

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.

Either way, though I sympathize with the desire to get rid of prefixes, there 
are other aspects (besides spec (re)formatting/massaging from wiki to W3C WD) 
that need more help if prefix-removal is your primary goal, e.g. we don't have 
a Fullscreen test suite nor even someone to curate/coordinate the creation of 
one - is that something you'd be available to help with?

Thanks,

Tantek

--Original Message--
From: Anne van Kesteren
Sender: whatwg-boun...@lists.whatwg.org
To: WHATWG
Subject: [whatwg] Fullscreen
Sent: Oct 3, 2011 01:17

Is anyone working on turning https://wiki.mozilla.org/Gecko:FullScreenAPI  
into a standard? It would be nice to get rid of the prefixes. I'm willing  
to work on it or help someone out if work is already going on. (I know I  
offered doing this last year, but then some DOM4 things came up and I left  
for three months. It should be better now.)


-- 
Anne van Kesteren
http://annevankesteren.nl/

Re: [whatwg] Question: rel=help

[Tantek Çelik]

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 respective element's title attribute or with a 
nearby/adjacent element) so that it is available without JS, and then if you 
wish to do fancy tooltip effects feel free to provide them with JS (progressive 
enhancement) which re-uses that content from the page.

Thanks,

Tantek

-Original Message-
From: Schalk Neethling sneethl...@mozilla.com
Sender: whatwg-boun...@lists.whatwg.org
Date: Thu, 29 Sep 2011 19:34:40 
To: Anne van Kesterenann...@opera.com
Reply-To: sneethl...@mozilla.com
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Question: rel=help

Hi Anna,

I heard some mention of using the data-* attributes so, something like:
a href= data-tooltip=Some help text/a

or

input type=text data-tooltip=Some help text /

Would you agree that this is the better option?

On 29/09/2011 16:50, Anne van Kesteren wrote:
 On Thu, 29 Sep 2011 16:35:33 +0200, Schalk Neethling
 sneethl...@mozilla.com wrote:
 Question, would an element with rel=help and a title=Help text
 make sense and be valid as a JavaScript hook for tooltips?

 Does not match the usage as described by the WHAT-WG
 (http://developers.whatwg.org/links.html#link-type-help) exactly, but
 close enough?

 If there is no actual hyperlink, using a link relation does not make sense.



-- 
Kind Regards,
Schalk Neethling
Mozilla Corporation

Re: [whatwg] Question: rel=help

[Tantek Çelik]

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.)

 Except in cases where the information is relevant only when JavaScript is
 enabled.

That's a reasonable theory. Do you have URLs to any real world examples?


 But the original question did not imply, as far as I can see, any
 JavaScript-only idea. On the contrary, using the title=... attribute
 implies that the text will be available to many people graphic browsers
 (though perhaps just by accident) and to many people using speech-based
 browsing.

Agreed.


 Consider adjusting your content design to incorporate the help text
 instead
 (perhaps with either the respective element's title attribute or with

 a nearby/adjacent element)

 I think that idea was implied in the question:

 Question, would an element with rel=help and a title=Help text
 make sense and be valid as a JavaScript hook for tooltips?

Realizing that this example markup was ambiguous - that is:

Does the string Help text represent a hypothetical placeholder on a
span or div etc.?

Or is that markup part of a hyperlink that links to a separate help
document? E.g.
a rel=help title=Help text href=help.html(?)/a


 I stll think it's best, for all users, to give instructions in normal text
 before the fields to be filled out.

Agreed.


 But there are situations where you
 expect 80% of people do well without any instructions.

Again, seems like a reasonable theory.

Do you have URLs to real world examples thereof?


 I'm not sure of what
 we are expected to do, as authors, in order to give instructions that might
 be needed by 20% of users but would mostly be a distraction for the
 majority.

Theoretical problems are harder to provide specific answers for, but
this might work:

Try the details and summary elements.

http://html5doctor.com/the-details-and-summary-elements/

Thanks,

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

Re: [whatwg] adding microdata to basic links

[Tantek Çelik]

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 book has been authored by a href=http://smith.org/john;John
  Smith/a.
  ]]]
 
  I would like to markup both the textContent of the link (John Smith)
 and
  the url from the href attribute.
 
  In RDFa this is done by adding a couple of attributes to the a element.
 It
  would read like this:
  [[[
  This book has been authored by a property=name rel=url href=
  http://smith.org/john;John Smith/a.
  ]]]

Stéphane, this looks like an incomplete example - how does a parser
know where the object that has name and url property starts and ends,
is it the whole page? The nearest common ancestor element? AKA how
does a parser determine the scope of the object?

And are name and url intended to be page-specific properties, or
do they belong to a theoretical shared vocabulary?

Could you provide a complete RDFa example of what you're attempting to
accomplish?


  Is there any way to do the same in microdata without adding a new HTML
  element to the markup?

 No, Microdata purposely keeps its data model simple by expressing
 property names through a single attribute.

One person (parser developer's) simple, is another person's (web
author/designer/publisher) odd new strange way, and thus far from
simple. It's a trade-off rather than being simple in any absolute
terms.


  Since having @itemprop on
 an a always refers to the @href of the element, you must nest an
 additional element, such as a span, into your markup to carry the
 property that refers to the text content.

This does seem to be a (fairly common) case where microdata requires
additional markup (another element) whereas both microformats (e.g.
hCard) and microdata (through the perhaps questionable overloading of
'rel') do not.

Stéphane, if you could provide a complete RDFa example of the
content example you gave, I'd like to see what Tab (or anyone else)
sees as an ideal way to mark it up with microdata instead for
comparison purposes.

Thanks,

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

Re: [whatwg] a rel=attachment

[Tantek Çelik]

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. Clean, simple, 
orthogonal.

Tantek
-Original Message-
From: Glenn Maynard gl...@zewt.org
Sender: whatwg-boun...@lists.whatwg.org
Date: Fri, 15 Jul 2011 19:43:45 
To: Jonas Sickingjo...@sicking.cc
Cc: whatwgwha...@whatwg.org; Darin Fisherda...@chromium.org; 
ife...@google.com
Subject: Re: [whatwg] a rel=attachment

2011/7/15 Jonas Sicking jo...@sicking.cc

 It definitely is an interesting usecase that Glenn brought up about
 being able to specify a save-as name without otherwise modifying the
 behavior of a reference. However that seems like a much more rare
 usecase and so not the one we should optimize for.


Bear in mind that optimize for doesn't mean support at all; if
download=filename is used, it seems unlikely that there will ever be *any*
client-side way to supply the filename without implying attachment, which is
a very different thing than not optimizing for it.

I don't feel strongly enough about this to press it further, but a
href=ugly download filename=pretty also seems fairly clean, and avoids
combining parameters that really are orthogonal to one another.

-- 
Glenn Maynard

Re: [whatwg] a rel=attachment

[Tantek Çelik]

Specs *and* publishers/consumers/implementations of rel-enclosure exist (see 
aforementioned wiki page). And the name is based on re-using the existing term 
with the same semantic from the Atom spec.

Sorry but the paint on that bikeshed dried a long time ago in an IETF working 
group far away. ;)

Tantek

-Original Message-
From: Peter Kasting pkast...@google.com
Date: Fri, 15 Jul 2011 18:20:54 
To: tan...@cs.stanford.edu
Cc: Glenn Maynardgl...@zewt.org; whatwg-boun...@lists.whatwg.org; Jonas 
Sickingjo...@sicking.cc; whatwgwha...@whatwg.org; Darin 
Fisherda...@chromium.org; ife...@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 find the fact that a spec exists for it a compelling
reason to use it.  (Specs exist for lots of things, many of them bad.)

PK

[whatwg] proposal: extend time to markup durations

[Tantek Çelik]

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 the hMedia and hAudio
microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal, examples, faq, discussion (please contribute)

http://wiki.whatwg.org/wiki/Time_element#duration

Thanks,

Tantek

[1] http://microformats.org/wiki/h2vx#HTML5_support

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

Re: [whatwg] a rel=attachment

[Tantek Çelik]

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 documents as an
  example). Traditionally the only way to achieve this is to set a
  content-disposition header. *However, sometimes it is not possible for
 the
 

 This has been raised a couple times:

 http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html

 http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread
 was derailed partway through)

 I've wanted this several times and I'm strongly in favor of it.


 Yes, it seems very useful.

Indeed, and has been pointed out, already specified (since 2005) and
implemented as well for HTML:

http://microformats.org/wiki/rel-enclosure

re-using the enclosure term from the Atom format (thus minimal bikeshedding)


 After mulling this over with some application developers who are trying to
  use this functionality, it seems like adding a rel attribute to the a
  tag would be a straightforward, minimally invasive way to address this
 use
  case. a rel=attachment href=blah.pdf would indicate that the browser
 

 This isn't enough; the filename needs to be overridable as well, as it is
 with Content-Disposition.  My recommendation has been:

 a href=image.jpg download
 a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg download=picture.jpg

 where the first is equivalent to Content-Disposition: attachment, and the
 second is equivalent to Content-Disposition: attachment;
 filename=picture.jpg.


 This is an interesting variation!  I like that it addresses the issue of
 providing a name for the download.  Using the term download here is also
 nice.

Agreed.

I've captured the suggestion on a brainstorming page:

http://microformats.org/wiki/rel-enclosure-brainstorming

Feel free to contribute or iterate.

Thanks,

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

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

[Tantek Çelik]

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 considered an anti-pattern, evidenced
by the fact that they (cite, longdesc, profile etc.) have all failed
to get any meaningful uptake among web developers).

On slightly a more positive note:

On Thu, Jul 14, 2011 at 12:35, Karl Dubost ka...@opera.com wrote:

 Le 14 juil. 2011 à 14:59, Kevin Marks a écrit :
 If I was writing a detector for this pattern, a followed by a colon
 and  blockquote would do it pretty reliably...

 yup unfortunately there are also many cases where you have more names in an 
 introducing paragraph. It is happening when I'm writing, and the issue is 
 then to tie the right person with the right blockquote/q

 I like the pattern id/for pattern of forms. We could imagine

 p
 span for=quoteA class=authorSir John Typo/span
 has written plenty of a wonderful thing
 in cite for=quoteAAmazing title/cite very similar to those in
 span for=quoteB class=authorSusan Spellchecker/span's writings

 blockquote id=quoteA
 […]
 /blockquote

 compare to cite for=quoteBAmazing title/cite

 blockquote id=quoteB
 /blockquote

I really like this pattern.

label for=input-id is a known working and in use pattern.

Thus I feel much more confident advocating use of the parallel:

cite for=quote-id

With one concern - multiple blockquotes. Thus the for attribute should
be a space separated set of IDREFs. E.g. this pattern (often seen on
blog posts analyzing articles and other blog posts)

cite for=quote1 quote2Some quoted title of a work/cite
blockquote id=quote1 one quotation /blockquote
p .. intervening commentary .. /p
blockquote id=quote2 another quotation /blockquote
p .. more commentary ../p

Though that example is vulnerable to bad copy/paste errors. It
requires two markup updates (done consistently) for each copy/paste: a
new id on each new blockquote, and having to update the original cite
element for each additional blockquote.


That example redone with today's cite attribute would be:

cite id=cite1Some quoted title of a work/cite
blockquote cite=#cite1 one quotation /blockquote
p .. intervening commentary .. /p
blockquote cite=#cite1 another quotation /blockquote
p .. more commentary ../p

which is then much more copy/paste proof if/when the author adds more
blockquotes from the same source that they're commenting on - fewer
bits of markup (none) to update.

So I don't know. Perhaps cite for handles the 80/20 one cite / one
quote case better and that's good enough to add it, and then perhaps
we keep the old cite= attribute for the one cite / multiple quote
case?

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

Re: [whatwg] a rel=attachment

[Tantek Çelik]

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 (イアンフェッティ) 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 documents as
   an
   example). Traditionally the only way to achieve this is to set a
   content-disposition header. *However, sometimes it is not possible
   for
  the
  
 
  This has been raised a couple times:
 
 
  http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
 
 
  http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread
  was derailed partway through)
 
  I've wanted this several times and I'm strongly in favor of it.
 
 
  Yes, it seems very useful.

 Indeed, and has been pointed out, already specified (since 2005) and
 implemented as well for HTML:

 http://microformats.org/wiki/rel-enclosure

 re-using the enclosure term from the Atom format (thus minimal
 bikeshedding)


  After mulling this over with some application developers who are trying
  to
   use this functionality, it seems like adding a rel attribute to the
   a
   tag would be a straightforward, minimally invasive way to address
   this
  use
   case. a rel=attachment href=blah.pdf would indicate that the
   browser
  
 
  This isn't enough; the filename needs to be overridable as well, as it
  is
  with Content-Disposition.  My recommendation has been:
 
  a href=image.jpg download
  a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg
  download=picture.jpg
 
  where the first is equivalent to Content-Disposition: attachment, and
  the
  second is equivalent to Content-Disposition: attachment;
  filename=picture.jpg.
 
 
  This is an interesting variation!  I like that it addresses the issue of
  providing a name for the download.  Using the term download here is
  also
  nice.

 Agreed.

 I've captured the suggestion on a brainstorming page:

 http://microformats.org/wiki/rel-enclosure-brainstorming

 Feel free to contribute or iterate.

 Thanks,

 Tantek


 Why do you feel it is important to specify rel=enclosure in addition to the
 download attribute?
 Thanks,
 -Darin

Other way around.

rel=enclosure is sufficient for today's use cases because authors
simply name the file accordingly on their server and then
implementations simply use the last segment of the URL as the filename
- presto 80/20 case solved (and solved 6 years ago with no
modification needed to HTML for it to be valid).

Having to specify a download attribute that reflects a filename
different from the last segment of the URL is the minority case, but
still sufficient to justify addition of the attribute.

Also the empty download attribute doesn't work as it is supposed to be
equivalent to download=download which would simply name the file
download which is unlikely what author or user want.

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

Re: [whatwg] Styling details

[Tantek Çelik]

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 styling of the details element,
 trying to figure out the most sensible way style it.  We have tried to
 find a solution that behaves the way authors expect, provides for easy
 restyling by authors and avoiding the troubles associated with magic
 styles that can't be expressed in CSS.

 The rendering section of the spec is currently very inadequate and does
 not describe accurate styles.  Also, the sample XBL binding given in the
 XBL 2.0 draft is also inadequate for a number of reasons.

 I think the long term solution here is some sort of widget definition
 binding language like XBL. I don't think it makes sense to do it purely in
 CSS. Discolsure widgets have all kinds of subtle behaviours like animation
 during disclosure, hover effects on the triangle, etc. Some systems use a
 More... or Details... button, some use a triangle, some use +/-.

 On the short term, I would recommend using the 'icon' property to allow
 authors to override the icon.

Agreed.

FYI: http://dev.w3.org/csswg/css3-ui/#icon

Feel free to follow-up feedback on that to www-st...@w3.org.

 I agree that what the spec says is currently inadequate, but without a
 binding language, I don't think it makes sense to spend time trying to
 improve it, since any improvement would be a stop-gap measure.

 The same applies to pretty much all the other form controls.

Also agreed.

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

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

[Tantek Çelik]

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 documentation of
additional examples, discussions, and follow-ups regarding the use of
cite for marking up names of speakers, including follow-ups to
common counter-arguments.

Please (re)consider explicitly allowing marking up speaker names with cite

More details, use-cases, research here:

http://wiki.whatwg.org/wiki/Cite_element#Speaker

I encourage fellow web authors and browser implementers to add their
opinions/comments to that wiki page section, *INSTEAD OF* in an email
thread - as I couldn't even find previous email threads on this topic.

Thanks!

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

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

[Tantek Çelik]

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 href=http://www.web2con.com/;http://www.web2con.com//a
  span class=summaryWeb 2.0 Conference/span:
  time class=dtstart datetime=2007-10-05October 5/time -
  time class=dtend datetime=2007-10-2019/time,
  at the span class=locationArgent Hotel, San Francisco, CA/span
 /div

(The end date is encoded as one day after the last date of the event
because in the iCalendar format, end dates are exclusive, not
inclusive.)
=== snip ===


Suggested update:
=== snip ===
div class=vevent
 a class=url href=http://www.web2con.com/;http://www.web2con.com//a
 span class=summaryWeb 2.0 Conference/span:
 time class=dtstart datetime=2005-10-05October 5/time-
 time class=dtend datetime=2005-10-077/time,
 at the span class=locationArgent Hotel, San Francisco, CA/span
/div
=== snip ===


Note: the parenthetical paragraph in the previous version about end
date inconsistency has been removed since hCalendar 1.0 has resolved
that issue (see dtend issue for details).


More details (if needed) on the wiki:

http://wiki.whatwg.org/wiki/Time_element#Update_hCalendar_example


Thanks,

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

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

[Tantek Çelik]

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 times asked for *duplicating* the data in a
different (more machine readable) format (or location).  This
experience yielded the microformats adoption of the DRY principle -
don't repeat yourself - in application to (meta)dataformat designs and
techniques.


The time element currently encourages DRY violations in most of its
use cases (duplication of datetime information inside the 'datetime'
attribute in addition to the visible content of the element). This is
not a new problem, we've had much the same DRY problem in microformats
representations of dates and times, originally with (excessive and in
many cases inaccessible) use of the abbr element.

Subsequently (through years of debate, experimentation, iteration)
we've largely addressed both most of the DRY violations (or greatly
mitigated their impact) and resolved accessibility related abbr
problems with the introduction and successful adoption of the Value
Class Pattern (developed in parallel with the time element, and not
surprisingly with some newer improvements).

http://microformats.org/wiki/value-class-pattern#Date_and_time_values


We'd like to see the lessons learned (and improvements made as a
result of the value class pattern) adopted in HTML5 as well, for much
the same reasons, to make the HTML5 time element the best and most
long term accurate way to represent all date and time information in
microformats (or microdata for that matter).

Accordingly, please consider the following time syntax processing
improvements for better DRY (and mitigation) and thus more accurate
data over time.


1. composite nested time elements.

In short, instead of this (actual example derived from markup of blog
post HTML5 watch[1] by Jeremy Keith)

time class=published datetime=2009-12-13T17:43:29
  Sunday, December 13th, 2009
  5:43pm
/time

We want to be able to do this:

time class=published
  time datetime=2009-12-13Sunday, December 13th, 2009/time
  time datetime=17:43:295:43pm/time
/time

and have the parent time element composite a complete datetime from
the child time elements with separate date and time.

The datetime values are more readable (per accessibility research
etc.), and thus more easily human verifiable as being the same value
as the in-content text, thus resulting in incrementally more accurate
data over time.

This type of date and time compositing as spec'd in the Value Class
Pattern has been interoperably implemented and shipped (Operator,
X2V).  Thus we think it is reasonable to add this similar feature to
HTML5.


More details, examples, use-cases here:

http://wiki.whatwg.org/wiki/Time_element#composite_nested_time_elements

I encourage web developers and browser implementers to add their
opinions and comments to that wiki page section.



2. am pm and coarser time parsing

Summary: by permitting am pm and coarser time values, many more
instances of time markup can be minimized to in-content only (not
requiring a datetime attribute) and thus reduce many DRY violations.

In short, instead of this (actual example derived from markup of blog
post HTML5 watch by Jeremy Keith, with nested time elements per
previous proposal)

time class=published
  time datetime=2009-12-13Sunday, December 13th, 2009/time
  time datetime=17:43:295:43pm/time
/time

We want to be able to do this:

time class=published
  time datetime=2009-12-13Sunday, December 13th, 2009/time
  time5:43pm/time
/time

It's a minor DRY improvement (time info is no longer duplicated), but
one that we think is worth it across the numerous pieces of content
authored as such and the resulting increased accuracy from DRY
reduction.

This type of am pm parsing as spec'd in the Value Class Pattern has
been interoperably implemented and shipped (Operator, X2V).  Thus we
think it is reasonable to add this similar feature to HTML5.


More details, examples, use-cases here:

http://wiki.whatwg.org/wiki/Time_element#am_pm_and_coarser_time_parsing

I encourage web developers and browser implementers to add their
opinions and comments to that wiki page section.


Thanks for your consideration,


Tantek


[1] http://adactio.com/journal/1632/

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

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

[Tantek Çelik]

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 output, and they should.

input type=date   - time-MM-DD/time
input type=datetime   - time-MM-DDTHH:MM:SS/time
input type=month  - not supported in current time element
input type=week   - not supported in current time element
input type=time   - timeHH:MM:SS/time
input type=datetime-local - timeHH:MM:SS-ZZ:YY/time
New proposed input elements:
input type=year   - not supported in current time element
input type=month-day  - not supported in current time element

From a design, learning/teaching perspective, it is much better if
they are made to match up, that is if every type/granularity of
datetime that can be entered can also be semantically marked up (and
vice versa).

Thus, please consider impedance matching time and datetime input types.

More details, use-cases, research here:

http://wiki.whatwg.org/wiki/Time_element#impedance_match_new_date_time_inputs

and related proposals:
* http://wiki.whatwg.org/wiki/Time_element#year_only
* http://wiki.whatwg.org/wiki/Time_element#year_month_only
* http://wiki.whatwg.org/wiki/Time_element#year_week_only
* http://wiki.whatwg.org/wiki/Time_element#month_day_only


I encourage fellow web authors and browser implementers to add their
opinions/comments to those wiki page sections.

Thanks!

Tantek



Related thread fragments from previous thread on new datetime inputs
(type=year, type=month-day) :

On Sun, Aug 8, 2010 at 6:19 PM, Ben Schwarz ben.schw...@gmail.com wrote:
 While creating an input that works for every use case you can think of
 sounds like a good idea, I'd like to question weather a user would ever
 enter a date that would require the inclusion of BC/AD.
 ...
 I'm certain that there is a requirement to markup such text,

It would be great if you could add your +1 accordingly to allowing
time to markup just a year:

http://wiki.whatwg.org/wiki/Time#year_only


 but as for
 entry I'm strongly of the opinion that you're over cooking this.

That may be.  My goal with these 2 additional datetime inputs (to the
current 6, thus making 8 total) was to not to be comprehensive but to
fill out what seemed to be a relatively similar set of datetime
inputs in terms of frequency of actual use cases.


On Sun, Aug 8, 2010 at 7:20 PM, Ben Schwarz ben.schw...@gmail.com wrote:

 ...

 Given that one of the principals of HTML5 is to have a well designed product
 that is easily understandable, I'd prefer to follow the path of simplistic,
 minimal design.

Ben, I tend to agree with those design principles.  In this case the
only reason I proposed those two additional input types (year,
month-day) is that they seem to naturally fit in with the existing 6
(month, week, date, datetime, datetime-local, time) and in seem just
as practically useful, if not more so, e.g. I see a lot more obvious
use-cases for the new input type=year as compared to the existing
input type=week for example.


 Not one where every example found will be implemented—I'd like to think that
 a browser vendor would find it very difficult to schedule the time to
 implement such a full featured method of handling every date representation
 known to man, rather than other awesome feature x.

Of course, and I tend to agree with your general analysis/reasoning.

Frankly, doing a good job on the existing 6 datetime inputs in general
is quite challenging/difficult, even with the progress/designs that
Opera and Safari have put forth.

However, from a design (visual, interactive) perspective, the 6
existing datetime inputs cover a sufficient diversity of cases that
if/when you (e.g. a browser implementer) do implement them, it's
pretty obvious/easy how to implement the 2 additional ones I've
proposed as variants.

I deliberately proposed adding input type=year and input
type=month-day both because of their utility/use-cases and
*specifically* because the marginal implementation cost of adding them
to the existing 6 is quite small in comparison to the marginal benefit
of said use-cases.



On Mon, Aug 9, 2010 at 7:10 AM, Daniel Glazman
daniel.glaz...@disruptive-innovations.com wrote:

 Tantek needs a year. He never said he needs to specify in
 which system the year is counted. He never said he cannot use
 a radiobutton for BC/AD or any other calendaring system
 aside of the year input.

 Why make things complex when it's possible to make them simple?

Right, I am ok with simply incrementally adding input type=year and
type=month-day within existing calendar/datetime constraints
(Gregorian assumption etc.) I believe the existing documented
use-cases justify this small addition.

Whether or not we explore additional calendaring systems (and their
use-cases) is perhaps 

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

[Tantek Çelik]

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 current new relative type of time, it makes
sense to add type=month-day as well (for a inputting a month and a
day without a year, e.g. for a birthday without birth year, or for
entering custom annual holidays).

More details, use-cases, research here:

http://wiki.whatwg.org/wiki/Input_element#new_date_time_inputs

I encourage fellow web authors and browser implementers to add their
opinions/comments to that wiki page section.

Thanks!

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

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

[Tantek Çelik]

On Sun, Aug 8, 2010 at 4:44 PM, Kit Grose k...@iqmultimedia.com.au wrote:
 How is a year input any different from a four-digit input type=number 
 field?
...
 I'm not sure what sort of additional validation you would need in a year 
 field that you couldn't accomplish with number, unless year is just an 
 alias for number with a size of 4.

It's not just an alias.

It is very similar, however different in that:
* it has the *semantic* of being a year, which is a special type of
number (potentially more than four digits if you subscribe to Long
Now[1] methodology, or fewer than four as Andy noted).
* this semantic gives browsers the opportunity to present a year
picker control that is styled in appearance consistently with other
datetime inputs (rather than just a number input)
* this semantic gives robots the opportunity to understand that a form
takes time based information rather than just a number (if for example
robots perform time based form submissions/searches on our behalf at
some point)


 Jakob Nielsen's testing has shown that forcing users to enter dates using 
 drop-down menus (or any other non-textual input) is a mistake: 
 http://www.useit.com/alertbox/20001112.html

This feedback is perhaps relevant to/if a browser (that) implements a
drop-down menu control for dates - nothing in this proposal suggests a
drop-down menu.


 I do see some value in the day  month combined input, since it can impose 
 simple rules like when to permit 30th/31st dates. I'm not entirely sure how 
 such an input would appear in visual UAs though;

Right - the specific visual appearance is up to UA designers.
Currently there is quite a bit of variance/experimentation of what
datetime inputs look like from browser to browser (e.g. Safari,
Opera), or even across different versions (Opera 10.55 vs 10.6) or
even across devices (Mobile Safari vs. Safari).


 a calendar would be inappropriate since the days of the week are tied to the 
 year, and the presence or otherwise of the 29th of February in such a control 
 would be difficult to present.

Again, good feedback to give a UA if it happens to do that.  Nothing
in the proposal requires what you suggest.


 Is it really an issue for this field to exist independently of the month and 
 day types just for things like validating the length of the months?

In my opinion the use cases for it are just as (if not more) common 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:

 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 current new relative type of time, it makes
 sense to add type=month-day as well (for a inputting a month and a
 day without a year, e.g. for a birthday without birth year, or for
 entering custom annual holidays).

 More details, use-cases, research here:

 http://wiki.whatwg.org/wiki/Input_element#new_date_time_inputs

 I encourage fellow web authors and browser implementers to add their
 opinions/comments to that wiki page section.

 Thanks!

 Tantek

 --
 http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5





-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

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

[Tantek Çelik]

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 only: 
* year-month only:  -MM (also corresponds to output form of input
type=month)
* year-week only: -WNN (also corresponds to output form of input type=week)
* month-day only: --MM-DD (common birthdays without year use case)

More details, use-cases, research here:
http://wiki.whatwg.org/wiki/Time#Date_granularity

I encourage fellow web authors and browser implementers to add their
opinions/comments to that wiki page section.

Note that there are additional proposals on that page - I'm sending
one email per proposal (or strongly related set of proposals) to
better track them separately. Feel free to read through and comment on
other proposals on the page as well.

Thanks!

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

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

[Tantek Çelik]

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 not actually solve the problem it is
 intending to solve.

 More details here:

 http://wiki.whatwg.org/wiki/Iframe_Sandbox

 I encourage fellow web authors and browser implementers to add their
 opinions/comments to that wiki page.

 As other have mentioned, iframe sandbox has been implemented in WebKit for 
 some time. Additional points of information:

 1) It's shipping in current versions of Safari and Chrome.
 2) Security experts have reviewed it. @sandbox itself seems pretty solid, 
 although there are possibly issues with related features such as 
 text/html-sandboxed and @seamless.
 3) Content has been built using it.
 4) While it's unclear if iframe sandbox will work well for comments or 
 other such cases of seamless untrusted content, it seems clearly useful for 
 use cases like gadgets and ads.

 While more security review is always welcome, it seems like the basic idea is 
 solid, and it's demonstrably implementable. The initial patch implementing it 
 for WebKit can be seen here: http://trac.webkit.org/changeset/51577. This 
 patch was 100k, but more than half of it is tests and the ChangeLog entry.


Ian, Adam, Maciej, I very much appreciate the follow-up information
you provided regarding this proposal.


I've captured it on the WHATWG wiki here:

http://wiki.whatwg.org/wiki/Iframe_Sandbox#why_sandbox_should_be_kept


The only outstanding requests I have are (on that wiki page)

1. Adam, it would be great if you could write up the summary of all the
security discussion - or at least provide links to some of it for
further reading.

http://wiki.whatwg.org/wiki/Iframe_Sandbox#security


2. Maciej, could you provide a few URLs to  content [that] has been
built using it. ?

http://wiki.whatwg.org/wiki/Iframe_Sandbox#examples_in_the_wild


3. Maciej, could you provide code examples for how sandbox could be
used for the use cases you mention of gadgets and ads?

http://wiki.whatwg.org/wiki/Iframe_Sandbox#use_cases


Thanks much,

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

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

[Tantek Çelik]

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 paragraph :), and a
potential enhancement to the HTML5-to-Atom conversion algorithm.

Alternatively, we could rename summary inside details to something
more specific so it won't be confused as a generic-sounding
element/feature.

More details here: http://wiki.whatwg.org/wiki/Summary

I encourage fellow web authors and browser implementers to add their
opinions/comments to that wiki page.

Thanks!

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

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

[Tantek Çelik]

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:

http://wiki.whatwg.org/wiki/Img_Alt

I encourage fellow web authors to add opinions/comments.

Thanks!

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

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

[Tantek Çelik]

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 fellow web authors and browser implementers to add their
opinions/comments to that wiki page.

Thanks!

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

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

[Tantek Çelik]

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 content inside a
time element rather than in invisible datetime attribute).
2. Better DRY (don't repeat yourself) by enabling sharing of a common
time element for multiple del/ins edits that occurred at the same
date/time.

More reasoning/advantages/opinions provided on the wiki:

http://wiki.whatwg.org/wiki/Del_element#timeref

I encourage fellow web authors to add opinions/comments to that wiki section.

Thanks!

Tantek


-- 
http://tantek.com/
I made an HTML5 tutorial video/book! http://tantek.com/html5

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

[Tantek Çelik]

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 that wiki page.

Thanks!

Tantek

-- 
http://tantek.com/
I made an HTML5 tutorial video/book! http://tantek.com/html5