Re: [webkit-dev] Implementation thoughts on HTML5 elements
On Dec 25, 2009, at 10:39 AM, TAMURA, Kent wrote: I made a master bug of HTML5, like HTML5 Forms already has. [Bug 32934] Master bug of HTML5 features https://bugs.webkit.org/show_bug.cgi?id=32934 A while back I made an HTML5 keyword, for HTML5 features and compliance bugs. I think HTML5 is probably too big to usefully handle with the master bug treatment. This particular bug barely scratches the surface. So I'd rather stick to using the keyword. I think master bugs work better for projects with a clearly defined scope. I also think a keyword search is a more useful view than the list of blocking bugs on a master bug: https://bugs.webkit.org/buglist.cgi?keywords=HTML5 Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
I made a master bug of HTML5, like HTML5 Forms already has. [Bug 32934] Master bug of HTML5 features https://bugs.webkit.org/show_bug.cgi?id=32934 On Wed, Aug 26, 2009 at 15:21, Maciej Stachowiak m...@apple.com wrote: Hi everyone, Recently at Apple we've been considering our plans to implement new HTML elements from HTML5. I'd like to share our thoughts with the WebKit community and see if we are in sync before passing this on to the HTML Working Group. Does anyone have thoughts to add to the below: -- - Sectioning elements: section, article, aside, hgroup, header, footer, nav These seem useful - they give a way to represent the semantics of many Web pages nicely, and could work well with accessibility features for navigating around the page, as well as other clever ways of processing Web content. They are also trivial to implement (I already did nav). We're fairly interested in doing the rest of these. - dialog element This essentially gives the same behavior as dl but with appropriate semantics for logs of conversations. It seems useful and easy to implement. - Elements requiring changes to legend parsing: figure, details These elements seem quite useful, but they will be unusable on the public Web until all browsers are updated to change how they parse legend and the new versions are widely adopted. Pretty much all current browsers do something idiosyncratic when parsing a legend element outside of a fieldset, which makes it impossible to make figure or details degrade gracefully via script or style. We are hesitant to implement elements that authors would feel they are unable to use, or to lead authors astray, so we are hesitant to implement the new elements until either the legend parsing issue is widely fixed or HTML5 uses some element other than legend for the caption on these elements. We will consider fixing our parsing of legend outside fieldset soon, though, so that we're not the blocker. - New media elements: audio, video We love these and have them implemented. We don't see any implementation issues in the current spec. - canvas We like this and we have it implemented. We don't see any implementation issues in the current spec. - Newly standard legacy elements: keygen, embed We had these for a long time before they were in HTML5. It seems like a good idea to cover them in the spec. - mark The basic idea for this element seems good, but the suggested UI for exposing it does not seem to entirely match the use cases, and may not be practical to deploy. Having tick marks in the scrollbar for every mark, and UI to cycle between them, seems too heavyweight for some of the suggested uses. We are interested in implementing the basics of mark soon, but probably not the requirements. - time It seems useful for use cases like Microformats to have a clean, unambiguous way to represent a specific time. It seems odd that there are ways to get Date objects to represent the date, time and time zone separately, but no way to get a Date representing the combination of date/time/timezone. Wouldn't the latter be a common use case, and doesn't the JavaScript Date object give sufficient APIs to unpack a Date into its components as needed? - New interactive controls: meter, progress These elements seem useful and a good idea. These controls are useful in native UI and often get hand-rolled by JavaScript libraries. We would like to expose a default native look, but with full author stylability for these. The only odd requirement is the use of inline text content in the elements to represent the state of the control. Specifying inline textContent may be a clever way to pass the initial state, but it seems very clunk as an interface for dynamically updating the state of the progress bar. Using the max and value IDL attributes of progress seems like it would be much easier for authors, and it seems like a problem that these only reflect the markup attributes and not the full state of the control (if the state is currently defined by text content). Likewise for the 6 attributes on meter. Assembling up to 6 numbers into a textContent string, which then does not cause the convenient DOM attributes to update, seems very clinky. - Ruby elements: ruby, rp, rt * We think these are useful. Google engineers are actively working on the WebKit implementation and some initial patches have landed.* - datalist Work on this is in progress. We think it is a good idea to offer a way to do true combo boxes, including ones with a dynamic source of filled-in values. - output This seems relatively simple to implement and worth implementing. - new input element types These seem generally useful, and we already have some implemented to various extents (search, range, email, url tel). The only concern is the sheer number of date and time controls. 6 of the 13 new input types are for dates or times. Are
Re: [webkit-dev] Implementation thoughts on HTML5 elements
On Dec 25, 2009, at 9:39 AM, TAMURA, Kent wrote: I made a master bug of HTML5, like HTML5 Forms already has. [Bug 32934] Master bug of HTML5 features https://bugs.webkit.org/show_bug.cgi?id=32934 Good to get this organized. But I think you generalized the topic a bit. I think that “HTML5 elements in WebKit” is a considerably narrower subject than “HTML5 features in WebKit”. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
On Aug 26, 2009, at 12:04 AM, Leo Meyerovich wrote: These are unnecessary features wrt accessiblity tools and search engines; data mining techniques can easily handle them already. More strongly, for legacy and advanced UI reasons, the data mining should happen anyways, further questioning their merit. That's been my experience in this area (from the analysis side). Features that provide actual functionality would seem more pressing. Can you please clarify what features you have in mind? Most of the new elements I mentioned do provide substantive functionality. Regards, Maciej - Leo Maciej Stachowiak wrote: On Aug 25, 2009, at 11:21 PM, Maciej Stachowiak wrote: Hi everyone, Recently at Apple we've been considering our plans to implement new HTML elements from HTML5. I'd like to share our thoughts with the WebKit community and see if we are in sync before passing this on to the HTML Working Group. Does anyone have thoughts to add to the below: -- I realized I forgot to cover command and menu. - menu The list form of a menu seems straightforward enough, it is good to have a list type specifically for popup menus. The toolbar form does not seem fully baked. First, it seems weird to think of a toolbar as a kind of menu. Second, the rendering is too inflexible and underspecified for the real Web content authoring use cases for toolbars. And finally, an important point of toolbars in many applications is that they can embed custom controls in a flexible layout that also includes some standard buttons, but menu type=toolbar does not seem flexible enough to handle this. The context menu form does seem genuinely useful. But it also seems like a lot of complexity for the somewhat marginal case of overriding the context menu. It seems like about a dozen different elements are allowed, all with different processing requirements. This seems like overkill for the use case of a context menu. It doesn't even make much semantic sense for a context menu to contain a button. Overall, it doesn't seem like the cases of menu list, toolbar and context menu really share enough behavior or appropriate content model to make them use the same element. - command It's unclear if this element is worth having without the use cases for toolbars or menus, and it also has 0 implementations so far and seems like it might not be fully baked. - Sectioning elements: section, article, aside, hgroup, header, footer, nav These seem useful - they give a way to represent the semantics of many Web pages nicely, and could work well with accessibility features for navigating around the page, as well as other clever ways of processing Web content. They are also trivial to implement (I already did nav). We're fairly interested in doing the rest of these. - dialog element This essentially gives the same behavior as dl but with appropriate semantics for logs of conversations. It seems useful and easy to implement. - Elements requiring changes to legend parsing: figure, details These elements seem quite useful, but they will be unusable on the public Web until all browsers are updated to change how they parse legend and the new versions are widely adopted. Pretty much all current browsers do something idiosyncratic when parsing a legend element outside of a fieldset, which makes it impossible to make figure or details degrade gracefully via script or style. We are hesitant to implement elements that authors would feel they are unable to use, or to lead authors astray, so we are hesitant to implement the new elements until either the legend parsing issue is widely fixed or HTML5 uses some element other than legend for the caption on these elements. We will consider fixing our parsing of legend outside fieldset soon, though, so that we're not the blocker. - New media elements: audio, video We love these and have them implemented. We don't see any implementation issues in the current spec. - canvas We like this and we have it implemented. We don't see any implementation issues in the current spec. - Newly standard legacy elements: keygen, embed We had these for a long time before they were in HTML5. It seems like a good idea to cover them in the spec. - mark The basic idea for this element seems good, but the suggested UI for exposing it does not seem to entirely match the use cases, and may not be practical to deploy. Having tick marks in the scrollbar for every mark, and UI to cycle between them, seems too heavyweight for some of the suggested uses. We are interested in implementing the basics of mark soon, but probably not the requirements. - time It seems useful for use cases like Microformats to have a clean, unambiguous way to represent a specific time. It seems odd that there are ways to get Date objects to represent the date, time and time zone separately, but no way
Re: [webkit-dev] Implementation thoughts on HTML5 elements
Maciej Stachowiak wrote: - New media elements: audio, video We love these and have them implemented. We don't see any implementation issues in the current spec. I played with the audio support about a month ago, and was unpleasantly surprised to find that if you loop audio there is a noticeable delay (sub-second, but very noticeable) between when the audio clip ended and then started again, in WebKit nightlies on the Mac. I posted a Q on the whatwg ml as to whether there was an intention that looped audio (and video, for that matter) should be seamless. Got various responses. AnneK responded that the intention was for it to be seamless. Ian responded that large clips couldn't be guaranteed to be buffered enough to make seamless audio a requirement. So there's some wiggle room in the spec. And of course, since the implementation of the audio support is a platform issue, not much we can do about this to magically make audio seamless for every platform. Still, seamless looping seems like something webkit ports should strive for. As an example, paste this into the snippet editor audio src=http://is.gd/2zHIy; autoplay=true loop=true You'll hear 4-5 seconds of static, then it pauses before it restarts. -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
On Aug 26, 2009, at 6:11 AM, Patrick Mueller wrote: Maciej Stachowiak wrote: - New media elements: audio, video We love these and have them implemented. We don't see any implementation issues in the current spec. I played with the audio support about a month ago, and was unpleasantly surprised to find that if you loop audio there is a noticeable delay (sub-second, but very noticeable) between when the audio clip ended and then started again, in WebKit nightlies on the Mac. I posted a Q on the whatwg ml as to whether there was an intention that looped audio (and video, for that matter) should be seamless. Got various responses. AnneK responded that the intention was for it to be seamless. Ian responded that large clips couldn't be guaranteed to be buffered enough to make seamless audio a requirement. So there's some wiggle room in the spec. And of course, since the implementation of the audio support is a platform issue, not much we can do about this to magically make audio seamless for every platform. Still, seamless looping seems like something webkit ports should strive for. As an example, paste this into the snippet editor audio src=http://is.gd/2zHIy; autoplay=true loop=true You'll hear 4-5 seconds of static, then it pauses before it restarts. Did you file the two bugs necessary here (hearing static, and non- seamless looping)? Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
On Wed, Aug 26, 2009 at 12:00 PM, Simon Frasersimon.fra...@apple.com wrote: Did you file the two bugs necessary here (hearing static, and non-seamless looping)? That static at least is intended (the audio file is just static.) -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
On Tue, Aug 25, 2009 at 11:45 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 25, 2009, at 11:21 PM, Maciej Stachowiak wrote: Hi everyone, Recently at Apple we've been considering our plans to implement new HTML elements from HTML5. I'd like to share our thoughts with the WebKit community and see if we are in sync before passing this on to the HTML Working Group. Does anyone have thoughts to add to the below: -- I realized I forgot to cover command and menu. - menu The list form of a menu seems straightforward enough, it is good to have a list type specifically for popup menus. The toolbar form does not seem fully baked. First, it seems weird to think of a toolbar as a kind of menu. Second, the rendering is too inflexible and underspecified for the real Web content authoring use cases for toolbars. And finally, an important point of toolbars in many applications is that they can embed custom controls in a flexible layout that also includes some standard buttons, but menu type=toolbar does not seem flexible enough to handle this. The context menu form does seem genuinely useful. But it also seems like a lot of complexity for the somewhat marginal case of overriding the context menu. It seems like about a dozen different elements are allowed, all with different processing requirements. This seems like overkill for the use case of a context menu. It doesn't even make much semantic sense for a context menu to contain a button. Overall, it doesn't seem like the cases of menu list, toolbar and context menu really share enough behavior or appropriate content model to make them use the same element. - command It's unclear if this element is worth having without the use cases for toolbars or menus, and it also has 0 implementations so far and seems like it might not be fully baked. While I don't disagree, I'm a little sad to see these not move forward in some form. JS libraries currently use a ridiculous amount of code to create simple flexible toolbars and menus that are keyboard accessible. Would be nice if someone with experience here (looking at you Hyatt) could chime in on whatwg with what a better design would look like so progress can be made. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
On Wed, Aug 26, 2009 at 10:47 AM, Ojan Vafaio...@chromium.org wrote: On Tue, Aug 25, 2009 at 11:45 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 25, 2009, at 11:21 PM, Maciej Stachowiak wrote: Hi everyone, Recently at Apple we've been considering our plans to implement new HTML elements from HTML5. I'd like to share our thoughts with the WebKit community and see if we are in sync before passing this on to the HTML Working Group. Does anyone have thoughts to add to the below: -- I realized I forgot to cover command and menu. - menu The list form of a menu seems straightforward enough, it is good to have a list type specifically for popup menus. The toolbar form does not seem fully baked. First, it seems weird to think of a toolbar as a kind of menu. Second, the rendering is too inflexible and underspecified for the real Web content authoring use cases for toolbars. And finally, an important point of toolbars in many applications is that they can embed custom controls in a flexible layout that also includes some standard buttons, but menu type=toolbar does not seem flexible enough to handle this. The context menu form does seem genuinely useful. But it also seems like a lot of complexity for the somewhat marginal case of overriding the context menu. It seems like about a dozen different elements are allowed, all with different processing requirements. This seems like overkill for the use case of a context menu. It doesn't even make much semantic sense for a context menu to contain a button. Overall, it doesn't seem like the cases of menu list, toolbar and context menu really share enough behavior or appropriate content model to make them use the same element. - command It's unclear if this element is worth having without the use cases for toolbars or menus, and it also has 0 implementations so far and seems like it might not be fully baked. While I don't disagree, I'm a little sad to see these not move forward in some form. JS libraries currently use a ridiculous amount of code to create simple flexible toolbars and menus that are keyboard accessible. Would be nice if someone with experience here (looking at you Hyatt) could chime in on whatwg with what a better design would look like so progress can be made. +1. Menus (menu strips, lists, what have you) and toolbars that share keyboard accelerators are a huge burden today, particularly in rich-text editing where focus constraints mean that in order to implement a11y for toolbars, you need to do lots of magical focus/selection saving in order to service the ad-hoc toolbar for things like keyboard navigation. Even if WebKit decides against the current HTML 5 spec for this stuff, having a toolbar and menu system that's sufficient for implementing the states needed for a rich text editor (think drop-down menus from a toolbar, toggle-buttons corresponding to style application, button-sets for multiple state toggles, e.g. alignment, etc.) would go a very long way to making a lot of UIs load faster and suck less (since, hopefully, a browser-provided UI would remove the ad-hoc nature of much of these UIs). Regards ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
On Aug 26, 2009, at 10:47 AM, Ojan Vafai wrote: On Tue, Aug 25, 2009 at 11:45 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 25, 2009, at 11:21 PM, Maciej Stachowiak wrote: Hi everyone, Recently at Apple we've been considering our plans to implement new HTML elements from HTML5. I'd like to share our thoughts with the WebKit community and see if we are in sync before passing this on to the HTML Working Group. Does anyone have thoughts to add to the below: -- I realized I forgot to cover command and menu. - menu The list form of a menu seems straightforward enough, it is good to have a list type specifically for popup menus. The toolbar form does not seem fully baked. First, it seems weird to think of a toolbar as a kind of menu. Second, the rendering is too inflexible and underspecified for the real Web content authoring use cases for toolbars. And finally, an important point of toolbars in many applications is that they can embed custom controls in a flexible layout that also includes some standard buttons, but menu type=toolbar does not seem flexible enough to handle this. The context menu form does seem genuinely useful. But it also seems like a lot of complexity for the somewhat marginal case of overriding the context menu. It seems like about a dozen different elements are allowed, all with different processing requirements. This seems like overkill for the use case of a context menu. It doesn't even make much semantic sense for a context menu to contain a button. Overall, it doesn't seem like the cases of menu list, toolbar and context menu really share enough behavior or appropriate content model to make them use the same element. - command It's unclear if this element is worth having without the use cases for toolbars or menus, and it also has 0 implementations so far and seems like it might not be fully baked. While I don't disagree, I'm a little sad to see these not move forward in some form. JS libraries currently use a ridiculous amount of code to create simple flexible toolbars and menus that are keyboard accessible. I think part of the problem with menu is that it doesn't really address either of those use cases. Would be nice if someone with experience here (looking at you Hyatt) could chime in on whatwg with what a better design would look like so progress can be made. I'll talk to Hyatt about this today. I agree that a good way to do toolbars, context menus, and even your classic list-based hover menu would be worthwhile. Our concerns are about the current design, and we're not sure there is time to fix it by Last Call. I'm going to let this thread go at least a few more days before compiling the feedback for the HTML WG. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
Simon Fraser wrote: On Aug 26, 2009, at 6:11 AM, Patrick Mueller wrote: As an example, paste this into the snippet editor audio src=http://is.gd/2zHIy; autoplay=true loop=true You'll hear 4-5 seconds of static, then it pauses before it restarts. Did you file the two bugs necessary here (hearing static, and non-seamless looping)? Ryan is correct; you are SUPPOSED to hear static. That was the first clip I found on the web this morning that would demonstrate the issue. Maciej has also suggested filing a bug, so I'll do that. -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
Hi, I don't think overriding the context menu is a marginal case. I think its very widely used in web applications. Tali On Wed, Aug 26, 2009 at 7:47 PM, Ojan Vafai o...@chromium.org wrote: On Tue, Aug 25, 2009 at 11:45 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 25, 2009, at 11:21 PM, Maciej Stachowiak wrote: Hi everyone, Recently at Apple we've been considering our plans to implement new HTML elements from HTML5. I'd like to share our thoughts with the WebKit community and see if we are in sync before passing this on to the HTML Working Group. Does anyone have thoughts to add to the below: -- I realized I forgot to cover command and menu. - menu The list form of a menu seems straightforward enough, it is good to have a list type specifically for popup menus. The toolbar form does not seem fully baked. First, it seems weird to think of a toolbar as a kind of menu. Second, the rendering is too inflexible and underspecified for the real Web content authoring use cases for toolbars. And finally, an important point of toolbars in many applications is that they can embed custom controls in a flexible layout that also includes some standard buttons, but menu type=toolbar does not seem flexible enough to handle this. The context menu form does seem genuinely useful. But it also seems like a lot of complexity for the somewhat marginal case of overriding the context menu. It seems like about a dozen different elements are allowed, all with different processing requirements. This seems like overkill for the use case of a context menu. It doesn't even make much semantic sense for a context menu to contain a button. Overall, it doesn't seem like the cases of menu list, toolbar and context menu really share enough behavior or appropriate content model to make them use the same element. - command It's unclear if this element is worth having without the use cases for toolbars or menus, and it also has 0 implementations so far and seems like it might not be fully baked. While I don't disagree, I'm a little sad to see these not move forward in some form. JS libraries currently use a ridiculous amount of code to create simple flexible toolbars and menus that are keyboard accessible. Would be nice if someone with experience here (looking at you Hyatt) could chime in on whatwg with what a better design would look like so progress can be made. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
Le 26 août 09 à 12:29, Michelangelo De Simone a écrit : 2009/8/26 Anthony Ricaud rik...@gmail.com: I'm concerned about the actual implementation of email, url, tel and number. In shipping versions of Safari (and maybe other browsers ?), those are exposed but without new functionality. We're working on such functionalities: static validation for type=url and type=email inputs is on its way, you may be interested in bug 27456 and 27457. -- Bye, Michelangelo Sorry, I wasn't clear enough in my explanation. I was talking about functionality such as Adress Book or History connection (for email, tel or url) or + and - buttons for numbers. The kind of features that web developers expect when input.type != text (like in Opera) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
On Wed, Aug 26, 2009 at 3:04 PM, Michelangelo De Simone micde...@gmail.comwrote: speaking about type=email a UI element which fetches email addresses from user's address book seems a happy choice to me. Consider that if the user uses a web mail app (e.g. Gmail) the UA will have no way of getting that data. In fact, the UA may not even know what mail client the user prefers to use, especially if he uses several different ones. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
Le 27 août 09 à 00:03, Peter Kasting a écrit : On Wed, Aug 26, 2009 at 2:59 PM, Anthony Ricaud rik...@gmail.com wrote: Sorry, I wasn't clear enough in my explanation. I was talking about functionality such as Adress Book or History connection (for email, tel or url) or + and - buttons for numbers. The kind of features that web developers expect when input.type != text (like in Opera) I'm not sure why or how web developers are relying on type=email, tel, or URL to have a UA hook to some sort of local address book or history. Why because such behavior is not specced anywhere (and is outside the scope of HTML5) and is unlikely to be the same between browsers, and how because I don't see how a web author would compensate in the case of no type=url support (for example) by providing a hand-rolled history list -- that data is not available to the author. PK For input type=number, Opera and WebKit patches (https://bugs.webkit.org/show_bug.cgi?id=27968 ) provide a UI to help selecting a number. This is something authors can provide through JS when it's not handled by the browser. And they can only use the DOM type to check for that. For other types (email, tel, url), sure, authors can't implement anything similar. But they can style them differently, offer indications on how to fill them, etc. One of the reason to use new input types in HTML5 is that they degrade gracefully, offering hooks to authors to enhance their pages for browsers not supporting them while providing the native version for browsers supporting them. That's no longer possible if new types are exposed without new functionality.___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
On Wed, Aug 26, 2009 at 3:49 PM, Anthony Ricaud rik...@gmail.com wrote: For other types (email, tel, url), sure, authors can't implement anything similar. But they can style them differently, offer indications on how to fill them, etc. One of the reason to use new input types in HTML5 is that they degrade gracefully, offering hooks to authors to enhance their pages for browsers not supporting them while providing the native version for browsers supporting them. That's no longer possible if new types are exposed without new functionality. Yes, you said as much already. I maintain that there's no UI for email, tel, url that authors can expect a UA to provide, and not providing things like integration with a system address book is not exposing a new type without new functionality in the sense that the UA is somehow lacking something in the spec. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
On Aug 26, 2009, at 3:53 PM, Peter Kasting wrote: On Wed, Aug 26, 2009 at 3:49 PM, Anthony Ricaud rik...@gmail.com wrote: For other types (email, tel, url), sure, authors can't implement anything similar. But they can style them differently, offer indications on how to fill them, etc. One of the reason to use new input types in HTML5 is that they degrade gracefully, offering hooks to authors to enhance their pages for browsers not supporting them while providing the native version for browsers supporting them. That's no longer possible if new types are exposed without new functionality. Yes, you said as much already. I maintain that there's no UI for email, tel, url that authors can expect a UA to provide, and not providing things like integration with a system address book is not exposing a new type without new functionality in the sense that the UA is somehow lacking something in the spec. The site doesn't rely on the UA providing a nice UI, but by setting these attributes it allows a UA that *can* provide an enhanced user experience to do so. For instance type=search does not have to do anything, but on UAs that support it, it can maintain things like search history or whatnot. There is also the potential for these attributes to allow improved support for accessibility or input methods. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
Lots of stuff on the web is best-effort, particularly when system integration is the point. I'm not sure that saying the experience will be different changes what semantics should be available to authors in any way. Regards On Wed, Aug 26, 2009 at 3:25 PM, Peter Kastingpkast...@google.com wrote: On Wed, Aug 26, 2009 at 3:23 PM, Michelangelo De Simone micde...@gmail.com wrote: 2009/8/27 Peter Kasting pkast...@google.com: Consider that if the user uses a web mail app (e.g. Gmail) the UA will have no way of getting that data. In fact, the UA may not even know what mail client the user prefers to use, especially if he uses several different ones. Implementing such functionality in a port-specific way may address this My main point is that it's clearly not possible to offer an identical experience for all users in all UAs, so I can't see how a web author could be relying on such a thing, and thus I can't see how _not_ having it in the current WebKit implementation is somehow harming web authors. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
