Re: [whatwg] text-format discussion from today's call
On Sun, Aug 8, 2010 at 12:34 PM, Ian Hickson i...@hixie.ch wrote: (This is presumably slightly off-topic, for which I apologise. I've set follow-ups to the WHATWG list.) On Sat, 7 Aug 2010, Silvia Pfeiffer wrote: However I've looked at what Ian is up to recently, and I think that TTML could map fairly well into his evolving architecture, so all we need to make sure is that he doesn't explicitly rule it out. I also would prefer to keep the track platform open to any file format. The track element as specced in the WHATWG HTML spec is intended to be format-agnostic. If there's anything that implies otherwise, please send feedback to the WHATWG list. (There may already be such feedback, in which case I will correct the problem in a few weeks when I get to that mail; right now I'm going through mail from around April.) Hi Ian, thanks for clarifying this - I guess because WebSRT is specified inside HTML5 in WHATWG I assumed it was only open for WebSRT, and because the rendering is also only specified based on WebSRT features, that confirmed that assumption. I have indeed sent much feedback on WHATWG, some of which are certain to be misunderstandings that need clarification. Looking forward to moving it along! Cheers, Silvia.
[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 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
How is a year input any different from a four-digit input type=number field? 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 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. 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; 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. 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? —Kit 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
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Mon, August 9, 2010 00:44, Kit Grose wrote: How is a year input any different from a four-digit input type=number field? Years can be more of fewer than four digits. Julius Caesar was born in 100 BC, for instance, while Manius Acilius Glabrio was consul in 91 AD. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
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
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
The field being four digits long doesn't restrict its contents to four digits only. I suppose you do raise an interesting concern; should the year field also permit the entry of BC/AD? If so, that might invalidate the ability to use a number field; you'd need to use a validation pattern on a standard text field. —Kit On 09/08/2010, at 10:46 AM, Andy Mabbett wrote: On Mon, August 9, 2010 00:44, Kit Grose wrote: How is a year input any different from a four-digit input type=number field? Years can be more of fewer than four digits. Julius Caesar was born in 100 BC, for instance, while Manius Acilius Glabrio was consul in 91 AD. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
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, but as for * entry* I'm strongly of the opinion that you're over cooking this. On Mon, Aug 9, 2010 at 11:11 AM, Kit Grose k...@iqmultimedia.com.au wrote: The field being four digits long doesn't restrict its contents to four digits only. I suppose you do raise an interesting concern; should the year field also permit the entry of BC/AD? If so, that might invalidate the ability to use a number field; you'd need to use a validation pattern on a standard text field. —Kit On 09/08/2010, at 10:46 AM, Andy Mabbett wrote: On Mon, August 9, 2010 00:44, Kit Grose wrote: How is a year input any different from a four-digit input type=number field? Years can be more of fewer than four digits. Julius Caesar was born in 100 BC, for instance, while Manius Acilius Glabrio was consul in 91 AD. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
How about a pull-down for Wikipedia which lets you choose the year or period? Or a charting application which looks at trends in history. While some uses may be more common than others, I personally favor going the extra kilometre to allow full expressiveness for whatever ranges are allowed. Brett On 8/9/2010 9:19 AM, Ben Schwarz 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, but as for /entry/ I'm strongly of the opinion that you're over cooking this. On Mon, Aug 9, 2010 at 11:11 AM, Kit Grose k...@iqmultimedia.com.au mailto:k...@iqmultimedia.com.au wrote: The field being four digits long doesn't restrict its contents to four digits only. I suppose you do raise an interesting concern; should the year field also permit the entry of BC/AD? If so, that might invalidate the ability to use a number field; you'd need to use a validation pattern on a standard text field. —Kit On 09/08/2010, at 10:46 AM, Andy Mabbett wrote: On Mon, August 9, 2010 00:44, Kit Grose wrote: How is a year input any different from a four-digit input type=number field? Years can be more of fewer than four digits. Julius Caesar was born in 100 BC, for instance, while Manius Acilius Glabrio was consul in 91 AD. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Mon, August 9, 2010 02:19, Ben Schwarz 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, but as for * entry* I'm strongly of the opinion that you're over cooking this. It took only seconds to find: http://www.guernsey.net/~sgibbs/roman.html which requires (for some dates) entry of 1, 2, and 3-figure and BC years. Likewise: http://www.smart.net/~mmontes/ec-cal.html Please enter a year after A.D. 325 Consider also a site allowing a search of an archive of archaeological finds by year of origin. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Sun, Aug 8, 2010 at 6:42 PM, Andy Mabbett a...@pigsonthewing.org.uk wrote: On Mon, August 9, 2010 02:19, Ben Schwarz 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, but as for * entry* I'm strongly of the opinion that you're over cooking this. It took only seconds to find: http://www.guernsey.net/~sgibbs/roman.html which requires (for some dates) entry of 1, 2, and 3-figure and BC years. Likewise: http://www.smart.net/~mmontes/ec-cal.html Please enter a year after A.D. 325 Consider also a site allowing a search of an archive of archaeological finds by year of origin. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk Couldn't the BC/AD case be handled intuitively by a dropdown right next to the year field that contains those two options? -- ~Jonathan Castello P.S. I'm new to the list, don't kill me!
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
Because you can find an example isn't exactly what I would call a use case. Nor were those pages examples of best practice in any way, shape or form. I'd prefer that someone who really cares about this as a problem designs the best case solution for the problem that you've highlighted here, rather than shoehorning it in. Is there someone on this list who feels passionately enough to make some working examples and demos? On Mon, Aug 9, 2010 at 11:42 AM, Andy Mabbett a...@pigsonthewing.org.ukwrote: On Mon, August 9, 2010 02:19, Ben Schwarz 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, but as for * entry* I'm strongly of the opinion that you're over cooking this. It took only seconds to find: http://www.guernsey.net/~sgibbs/roman.html which requires (for some dates) entry of 1, 2, and 3-figure and BC years. Likewise: http://www.smart.net/~mmontes/ec-cal.html Please enter a year after A.D. 325 Consider also a site allowing a search of an archive of archaeological finds by year of origin. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On 09/08/2010, at 11:49 AM, Jonathan Castello wrote: Couldn't the BC/AD case be handled intuitively by a dropdown right next to the year field that contains those two options? Do you consider your own birth year to be, e.g., 1970 AD? Why stop there—do we need to also distinguish between Gregorian and Julian calendars? Doesn't it feel like a system for the edge cases at the expense of the majority of users? On 09/08/2010, at 11:07 AM, Tantek Çelik wrote: 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. That's not what the article says; it says *any* control that requires entry via the mouse (including calendars, drop-downs, sliders, etc.) as opposed to a naked text field hinders usability. Users can enter 1925 as numerals into a text field much quicker than any visual date picker can permit. —Kit
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Mon, August 9, 2010 02:59, Ben Schwarz wrote: Because you can find an example isn't exactly what I would call a use case. I didn't find an example, I found many - more than one of which I quoted, by way of illustration. What would you call a use case? Nor were those pages examples of best practice in any way, shape or form. These requirements are new to me. Where are they documented? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
[Apologies - I inadvertently sent this to Kit, not the list, so it's now out-of-sequence] On Mon, August 9, 2010 00:44, Kit Grose wrote: How is a year input any different from a four-digit input type=number field? P.S. and here are some published five-and six- figure years: http://en.wikipedia.org/wiki/11th_millennium_and_beyond e.g. 15790 April 20: Annular solar eclipse and a transit of Mercury. 571741: A simultaneous transit of Venus and the Earth from Mars Note that while both are on Wikipedia, they're each cited from other sources. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Mon, August 9, 2010 02:59, Ben Schwarz wrote: Because you can find an example isn't exactly what I would call a use case. I didn't find an example, I found many - more than one of which I quoted, by way of illustration. What would you call a use case? Nor were those pages examples of best practice in any way, shape or form. These requirements are new to me. Where are they documented? They aren't documented at all (afaik). Its a common design methodology to design for only what you actually require at a given time. There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we now know we don’t know. But there are also unknown unknowns. These are things we do not know we don’t know. 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. 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.
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Mon, August 9, 2010 03:20, Ben Schwarz wrote: On Mon, August 9, 2010 02:59, Ben Schwarz wrote: Because you can find an example isn't exactly what I would call a use case. I didn't find an example, I found many - more than one of which I quoted, by way of illustration. What would you call a use case? Nor were those pages examples of best practice in any way, shape or form. These requirements are new to me. Where are they documented? They aren't documented at all (afaik). Its a common design methodology to design for only what you actually require at a given time. I'm afraid my confusion is only deepening; you didn't say anything about what [we] actually require (why would you; the examples I gave demonstrated that the facility to input 1-, 2- and 3-digit and BC dates is currently required); you said that the examples I gave were not best practice in any way, shape or form. [...] 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. I don't recall anyone asking for handling every date representation known to man. On the other hand, I have demonstrated a requirement to be able to input every date known to man. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Prefetch issues
On Thu, 10 Jun 2010, Eric Schurman wrote: As described, the link prefetching capability seems to have some limitations that work counter to the performance of the page using it. It appears as though LINK elements are metadata elements and that these may only be supported inside the HEAD of the document. If so, then this is an issue in the real world, because at the time a web server flushes chunks containing the HEAD section of a document, the links we would want to prefetch are often not known. This is true for all the large sites I've analyzed or worked at. For example, many pages on a site will contain the same visual header, and we want to flush the HEAD and visual header content while the server is in the process of figuring out what the content of the page will be - which will contain the links we'd like to prefetch. Am I reading this correctly? This was indeed a limitation of the prefetch mechanism. One of the simplest approaches may be to add support for rel=prefetch to A and AREA's, but it's been explicitly excluded from those. Why? No good reason. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] proposal - link relations: rel=prefetch to be exchanged for a boolean attribute
On Mon, 5 Jul 2010, Ben Schwarz wrote: I'd find it useful if I could ask the user agent to prefetch the next page as its more than likely that the user will be lead to this page soon after the current browsing context. Having a linkrel of next is useful for styling. However, as far as my understanding goes, linkrels should not contain multiple values; eg: a rel=prefetch nextNext page/a This is in fact allowed. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Non-blocking SVG Canvas?
On 8/6/10 9:16 PM, Kevin Ar18 wrote: I think I would really like to get some input from people who have done some work on the SVG spec. :) www-...@w3.org is the right place for that. -Boris
Re: [whatwg] Feedback on the Mozilla FullScreen API proposal
Fullscreen support for specific elements is more than just a convenience - it's fairly common to have multiple elements on a page that could be made to go fullscreen, such as a page with multiple video players. For YouTube, we've chosen to put our embeddable player within an iframe, but I imagine some others will directly inline their player content. Mike, regarding your suggestions of element-level allow/deny attributes, I'm not sure I see how this can work. The root problem in your examples is that the page author is allowing untrusted content in their page. Ads should be sandboxed from the rest of the page for more than just prevention of fullscreen. -John On Fri, Aug 6, 2010 at 3:34 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Sat, Aug 7, 2010 at 1:57 AM, Mike Wilcox m...@mikewilcox.net wrote: Regarding fullscreen elements: I appreciate the initiative, but I wonder if it's necessary to allow fullscreen at the element level? It's not necessary, but it's a very useful convenience. It also allows the UA to perform transition effects that are impossible just at the author level. I think Simon is already pointing out potential gotchas. What exactly is the difference between a fullscreen-element and a fullscreen-page that has an element in absolutely position, top z-index, at 100% width and height? Nothing; see the proposed UA style sheet additions in the spec. As a developer, after entering fullscreen I could possibly do a fancy transition of the element to take up 100%. You can't do it as well as the UA can, because a really good transition effect involves desktop-level effects that authors don't have access to. For example you might want part of the window to zoom out and cover the entire screen, semi-transparent over the desktop while zooming. I would disrecommend authors trying to create custom transition effects that depend on geometry; they probably won't work across browsers because they'll interfere with the UA's effects. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Feedback on the Mozilla FullScreen API proposal
Fullscreen support for specific elements is more than just a convenience - it's fairly common to have multiple elements on a page that could be made to go fullscreen If the browser fullscreen API only supported making the entire page fullscreen, you could make an element fullscreen by making the page fullscreen and then making the element fill the page. This is in fact what the proposed API does. It just provides a convenient way for authors to achieve it. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Feedback on the Mozilla FullScreen API proposal
If there are multiple elements on the page (e.g. multiple inline video players) that could go fullscreen, you still need some way to determine which of them the user intended to make fullscreen. My understanding is that was the point of designating a fullscreen element - it still requires that elements cooperate (by checking to see that they are the intended fullscreen element), but it's possible for them to do the right thing. If fullscreen was initiated at the document level, then the intended behavior is ambiguous, and I would expect none of the elements to go fullscreen. -John On Sun, Aug 8, 2010 at 10:50 PM, Robert O'Callahan rob...@ocallahan.orgwrote: Fullscreen support for specific elements is more than just a convenience - it's fairly common to have multiple elements on a page that could be made to go fullscreen If the browser fullscreen API only supported making the entire page fullscreen, you could make an element fullscreen by making the page fullscreen and then making the element fill the page. This is in fact what the proposed API does. It just provides a convenient way for authors to achieve it. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
