[webkit-dev] LLINT Value Profiling
Hi All! As I understand llint does value profiling for all instructions which have memory access. However in DFG during predictionPropegtion pass this profile results using only for function arguments and return value. Am I right?? If yes, is it possible to use this result to predict types for local variables? Thanks for attention! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Github vs. git.webkit.org
2012/11/28 Adam Barth aba...@webkit.org: My sense is that the WebKit community would prefer that the hashes in GitHub match the hashes in git.webkit.org so that folks can more easily move branches between the two. For my part, I've switched over to using GitHub exclusive of git.webkit.org, so the the difference in hashes aren't an issue for me, but I can understand why they'd be problematic for other people. After the force-push, would you still be able to push updates automatically? If so, you can switch the hashes whenever is convenient for you. (It might be nice to announce the date/time on this list so that folks aren't taken by surprise.) Thanks for letting us use your mirror. I've found it very useful to be able to push work-in-progress branches to GitHub to share with folks. +1. If we are all set about this, it would be awesome if we could move on with it, Tor Arne! This would also avoid some extra work for Gergely Kis, I guess... cheers, jesus ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Github vs. git.webkit.org
Hi, Actually we already made the transition to the current github commit ids, because github wanted to shut down our repository, if it is not a fork of the semi-official webkit repository. Of course we will be able to transition back to the git.webkit.org commit ids, when the transition was made. I am just mentioning this, that you don't have to rush anything because of us. Best Regards, Gergely On Thu, Nov 29, 2012 at 3:53 PM, Jesus Sanchez-Palencia je...@webkit.orgwrote: 2012/11/28 Adam Barth aba...@webkit.org: My sense is that the WebKit community would prefer that the hashes in GitHub match the hashes in git.webkit.org so that folks can more easily move branches between the two. For my part, I've switched over to using GitHub exclusive of git.webkit.org, so the the difference in hashes aren't an issue for me, but I can understand why they'd be problematic for other people. After the force-push, would you still be able to push updates automatically? If so, you can switch the hashes whenever is convenient for you. (It might be nice to announce the date/time on this list so that folks aren't taken by surprise.) Thanks for letting us use your mirror. I've found it very useful to be able to push work-in-progress branches to GitHub to share with folks. +1. If we are all set about this, it would be awesome if we could move on with it, Tor Arne! This would also avoid some extra work for Gergely Kis, I guess... cheers, jesus ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Reminder: FOSDEM CrossDesktop DevRoom 2013 - Call for Talks
Hello, The Call for Talks for the CrossDesktop DevRoom at FOSDEM 2013 is officially open and will close in two weeks (Dec 14th). WebKit is used by many frameworks for hybrid appliations, kind-of bridging the web and desktop worlds. Sure there is a lot to say. Please submit your talk proposals ASAP! --8--- * FOSDEM is one of the largest gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium). One of the tracks will be the CrossDesktop DevRoom, which will host Desktop-related talks. We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperativity amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience. Topics accepted include, but are not limited to: Enlightenment, Gnome, KDE, Unity, XFCE, Windows, Mac OS X, general desktop matters, applications that enhance desktops and web (when related to desktop). Talks can be very specific, such as developing mobile applications with Qt Quick; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2012 schedule might give you some inspiration: https://archive.fosdem.org/2012/schedule/track/crossdesktop_devroom.html https://archive.fosdem.org/2012/schedule/track/crossdesktop_devroom.html Please include the following information when submitting a proposal: - Your name - The title of your talk (please be descriptive, as titles will be listed with around 250 from other projects) - Short abstract of one or two paragraphs - Short bio - Requested time: from 15 to 45 minutes. Normal duration is 30 minutes. Longer duration requests must be properly justified. The deadline for submissions is December 14th 2012. FOSDEM will be held on the weekend of 2-3 February 2013. Please submit your proposals to crossdesktop-devr...@lists.fosdem.org (subscribtion page for the mailing list: https://lists.fosdem.org/listinfo/crossdesktop-devroom ) -- The CrossDesktop DevRoom 2013 Organization Team* --8--- -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] pointer events specification - first editors draft
On Wed, Nov 28, 2012 at 5:53 PM, Benjamin Poulain benja...@webkit.org wrote: On Wed, Nov 28, 2012 at 8:23 AM, Adam Barth aba...@webkit.org wrote: I'm sympathetic to these concerns, but, unfortunately, I don't see any other path that leads to interoperability with Internet Explorer. Currently, there is little to no content that supports pointer events. There is also little to no demand for it for the reasons I mentioned before. It seems very likely that authors will write content that uses pointer events given that it's the only way to learn about touch input on IE 10 on Windows 8. If we don't implement pointer events, all of these web sites are going to have separate code paths for IE+Firefox and for Safari+Chrome. If we wait for this content to be authored before implementing pointer events, we'll have dug ourselves a deep hole that we'll spend years crawling out of. I would prefer WebKit to be wise and wait for either good use cases, or a better spec. In my view, the wise course of action is for all user agents to implement an interoperable set of input events so that authors don't need to have separate code paths for different user agents. As far as I can tell, the only candidate for those events are pointer events. I asked you before if you knew of any other paths to interoperability and you didn't respond. (Of course, that doesn't mean we should slavishly implement whatever Microsoft proposes. That's why there's a working group in the W3C: to refine and improve the feature's design and specification.) Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] LLINT Value Profiling
No. The type predictions come in via Node::getHeapPrediction() for those nodes that were generated from bytecodes that had value profiles. The bytecode parser sets the heap prediction (see OpInfo() arguments to addToGraph()) and the prediction propagator propagates those heap predictions to the normal predictions. -F On Nov 29, 2012, at 5:46 AM, wingoog moon wingoo...@gmail.com wrote: Hi All! As I understand llint does value profiling for all instructions which have memory access. However in DFG during predictionPropegtion pass this profile results using only for function arguments and return value. Am I right?? If yes, is it possible to use this result to predict types for local variables? Thanks for attention! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] pointer events specification - first editors draft
On Thu, Nov 29, 2012 at 10:27 AM, Adam Barth aba...@webkit.org wrote: I would prefer WebKit to be wise and wait for either good use cases, or a better spec. In my view, the wise course of action is for all user agents to implement an interoperable set of input events so that authors don't need to have separate code paths for different user agents. As far as I can tell, the only candidate for those events are pointer events. I asked you before if you knew of any other paths to interoperability and you didn't respond. I did not respond because that has nothing to do with my point. I wholeheartedly agree interoperability is good. What I am saying is no support is better than support for a bad ideas. We have synchronous XHR due to compatibility. If synchronous XHR was introduced today and I had a chance to prevent it, I would fight for it. (Of course, that doesn't mean we should slavishly implement whatever Microsoft proposes. That's why there's a working group in the W3C: to refine and improve the feature's design and specification.) That is all I ask. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Nov 26, 2012, at 2:01 PM, Steve Faulkner faulkner.st...@gmail.com wrote: I have submitted a patch [1] to add main element support to webkit and would appreciate your consideration. You should also add a layout test. From an accessibility perspective, the main element is an easy win. There is currently no element on which to hang the landmark, so expert web authors are forced to use ARIA on top of HTML5 div role=main, and non-experts miss an opportunity that would make their web content more accessible div id=main (semantically meaningless). On top of the major accessibility win, it's another organizational hook for scripts or CSS, like header or nav. I respond to some of the other comments in each sub-thread. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Nov 27, 2012, at 4:22 PM, Ian Hickson i...@hixie.ch wrote: ARIA is used by very few authors, and those authors are, by and large, much more competent than average. ARIA therefore tends to be used to a much higher level of quality than most elements. Yet this is part of the problem. One of the reasons most of the Web is not very accessible is because you have to be an expert in order to code an accessible site. Part of the goal of HTML 5 (and WebKit for that matter) should be to make it easy for authors to include accessibility support without having to think about it. [main] would probably be used about as well, maybe a little less well than [article, header, aside] because the idea of what is main varies from author to author (e.g. in the sites you analysed on the WHATWG list, as well as in many that others have mentioned before, id=main and id=content often include things like some navigation, some headers, some sidebars, some footers). This is valid, but if that's the worst case scenario, it's still exactly as good as the best-case scenario when there is no main element, so I don't really consider this to be much of an opposition. Besides, the scooby doo method could apply in those cases. If a main element contains article, header, aside or otherwise non-main content, browsers can it from what constitutes the main content. More importantly, the main element gives us a node on which to hang the landmark AXSubrole: AXApplicationMain which enables landmark navigation in supporting screen readers like VoiceOver. The use case for e.g. header is mainly one of maintenance and styling: lots of people style their headers very specifically. In general it doesn't matter if one author marks his navigation as being part of his header and another marks his navigation using nav; the result is the same: they are clearly marked in the source, they can be styled, and they can be skipped. If one author doesn't use it, or even if most authors use it incorrectly, it doesn't mean that other authors can't use it. The use case for main is accessibility navigation. It isn't true that the *only* use case is for accessibility. main is just as useful as a organizational maintenance and CSS styling hook as the header or nav elements. If authors use it incorrectly, the feature *doesn't work*. The element becomes pointless. This is also not true. Whether or not the main element contained other non-main content, the end effect is more or less the same. Screen reader users using landmark navigation would jump to the beginning of the first piece of content in the main element. Nested landmarks work fine, too. I don't think this argument is valid. This is like the difference between a href= and img longdesc=. Please don't dredge that one up. I'm a vocal opponent of @longdesc, but this is nothing like @longdesc. If many authors use longdesc= incorrectly, however, it means users who try to use the feature quickly stop expecting it to work and they give up and even pages that use it correctly lose out. Regarding @longdesc, I agree, but relating this problem to main is FUD. Main is not some external content to be forgotten; it's just a tag surrounding the main contents of the page. Even if there are slightly differing views of what constitutes the main content, you still get mostly useful semantic, styling, and accessibility benefits from main James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] New web-exposed feature: ruby-position: {before, after}
As specified in http://www.w3.org/TR/2011/WD-css3-ruby-20110630/#rubypos, the ruby-position property takes four values: before, after, inter-character, and inline. In http://trac.webkit.org/r136142 I added a -webkit-ruby-position property and support for the before and after values (the former, which is also the initial value of the property, corresponds to the existing behavior before the property was added). ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
Snipping somewhat for brevity… On Nov 27, 2012, at 8:02 PM, Ian Hickson i...@hixie.ch wrote: Sites have been quite happily working with a skip past navigation link Happily? Begrudgingly? For what it's worth, landmark navigation should not be confused with skip nav links. Think of it more like a hierarchical navigation, similar to jumping by heading, but with more semantics and at a higher level. , and HTML has an explicit nav element that makes this more likely to happen even for sites that don't provide a link, and ATs have all kinds of page navigation tools for users that let them jump around looking for whatever it is they want to read Landmark navigation is now one of these tools, why prevent authors from explicitly using it for main content? (which isn't necessarily the main content; e.g. on youtube.com you probably want the search box, not the stream, in many cases). That seems very subjective, and possibly off-topic. But secondly, how do you think main will do anything to make authors aware of anything? To authors who hear about the element, it's just going to be met with ah, a way to replace my id=main element ID with an element instead, just like header and nav. And if they do, that's fine, and we're still left with the main content via the scooby doo method. main nav … /nav p first bit of main content /p footer … /footer /main …but if they get it right, heuristics get even better. nav … /nav main p first bit of main content /p /main footer … /footer In either case, explicit landmark navigation to main could move the screen reader cursor to the first bit of main content… Without a main element, this is ambiguous: nav … /nav p first bit of main content /p p not main content /p footer … /footer Correct use clarifies the structure: nav … /nav mainp first bit of main content /p/main p not of main content /p footer … /footer And incorrect use frequently turns out fine anyway, and does not negatively affect use on other pages: main nav … /nav p first bit of main content /p p not main content /p !-- it might not be the main main content, but it doesn't make the feature useless as you've stated -- footer … /footer/main /main As you've pointed out, incorrect use of @alt on one page does not prevent other pages from using @alt correctly. Likewise incorrect use of main would not prevent a user from using other navigation mechanisms on this page, and does not deter a user from using it on other pages, and in many case, incorrect use of main would still work as a reasonable landmark. And thirdly, since when are awareness campaigns appropriate ways to do language design? We design to solve real problems, we try to make the platform intuitive. We don't design the language to teach people. That's the job of tutorials, advocacy, etc. No argument here. main is pretty intuitive, and the penalty for misunderstanding its use is next to nothing. Note that if it's misused even as much as the other semantic elements, that's enough to make it useless, unlike with those other elements. Again, I don't follow your logic. Even misused, it's still just as good as the scooby doo method, and misuse does not make it useless. I think we need to let go of the idea that main will replace id=main and id=content, because it's not the point of main. That's how authors will use it. That it's not the point of main is *exactly* the reason main is a bad design. That's how *some* authors *may* use it, but that's okay, even if they do. Ultimately, we always have the accessibility users as the testers for this feature and they can register bugs where the main element is leading to the wrong place. How well did that work for longdesc=? Irrelevant. @longdesc isn't implemented well due to other significant design problems. Heck, how well did it work for alt=? Pretty well actually. When a screen reader user hears an unlabeled button or image, they know exactly what is wrong, and what to report. Accessibility users complaining doesn't lead to sites getting fixed. We fix user-reported accessibility complaints all the time. So does your company, and many others. There are scores of blog posts and podcasts from indie iOS app developers talking about how they'd never heard of accessibility until a few vocal users of their apps spoke up, and these developers were able to fix their bugs with minimal effort, thanks to the fact that they were made aware of the problem by their loyal customers. In conclusion: A. Authors don't test their pages in a way that would detect this feature. Agreed, but they don't (and shouldn't) have to. B. Authors won't understand this feature. Disagree, but the cost of misunderstanding is negligible. C. If this feature is misused to any significant extent by a subset of authors, then the purpose of the feature is lost for all users on all sites. Disagree strongly, and I'd argue that you're
Re: [webkit-dev] Adding main element to WebCore
On Nov 28, 2012, at 12:43 AM, Maciej Stachowiak m...@apple.com wrote: role=main can achieve this, but sectioning elements take care of the other landmark roles, and it seems strange to have this be the odd one out. In my own judgment, this outweighs risk of misuse. I agree. On the other hand, this element does not add material functionality over what section role=main or div role=main would do, so the benefit is fairly small, compared to an element that does something authors couldn't do otherwise. (2) The implementation cost is pretty low, so the main consideration is whether this would benefit the Web. The significant benefit here is that we'll get a lot more more authors using main correctly, than we ever will using div role=main and that's a win for the accessibility of the Web as a whole. James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Thu, Nov 29, 2012 at 6:08 PM, James Craig jcr...@apple.com wrote: Snipping somewhat for brevity… This is an interesting standards debate but as many people have noted it does not belong on the webkit-dev list, which is for coordinating the development of WebKit. Please take this over to whatwg@ or some other appropriate standards list. - James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Nov 29, 2012, at 6:19 PM, James Robinson jam...@google.com wrote: This is an interesting standards debate but as many people have noted it does not belong on the webkit-dev list, which is for coordinating the development of WebKit. Please take this over to whatwg@ or some other appropriate standards list. I think it's valid to discuss here because this thread started as a request for comments on a patch. 1. This patch is valid for consideration because there is already an extension specification for HTML 5 that was approved for publish by consensus of the HTML Accessibility Task Force. 2. My feedback to Steve was that I supported the addition but he should include a layout test. 3. The patch discussion, however, was derailed IMO by misinformation about assistive technologies and how they are used in conjunction with WebKit, so I wanted a chance to contradict the misinformation at its source. James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Nov 29, 2012, at 6:33 PM, James Craig jcr...@apple.com wrote: On Nov 29, 2012, at 6:19 PM, James Robinson jam...@google.com wrote: This is an interesting standards debate but as many people have noted it does not belong on the webkit-dev list, which is for coordinating the development of WebKit. Please take this over to whatwg@ or some other appropriate standards list. I think it's valid to discuss here because this thread started as a request for comments on a patch. 1. This patch is valid for consideration because there is already an extension specification for HTML 5 that was approved for publish by consensus of the HTML Accessibility Task Force. One minor correction. This extension specification was approved with no objections and ample support by the main HTML Working Group, not just by the task force. http://lists.w3.org/Archives/Public/public-html/2012Nov/0232.html Which I believe means inclusion of the patch should be accepted once it gets reviewer approval, no? 2. My feedback to Steve was that I supported the addition but he should include a layout test. 3. The patch discussion, however, was derailed IMO by misinformation about assistive technologies and how they are used in conjunction with WebKit, so I wanted a chance to contradict the misinformation at its source. James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Thu, Nov 29, 2012 at 6:42 PM, James Craig jcr...@apple.com wrote: On Nov 29, 2012, at 6:33 PM, James Craig jcr...@apple.com wrote: On Nov 29, 2012, at 6:19 PM, James Robinson jam...@google.com wrote: This is an interesting standards debate but as many people have noted it does not belong on the webkit-dev list, which is for coordinating the development of WebKit. Please take this over to whatwg@ or some other appropriate standards list. I think it's valid to discuss here because this thread started as a request for comments on a patch. 1. This patch is valid for consideration because there is already an extension specification for HTML 5 that was approved for publish by consensus of the HTML Accessibility Task Force. One minor correction. This extension specification was approved with no objections and ample support by the main HTML Working Group, not just by the task force. http://lists.w3.org/Archives/Public/public-html/2012Nov/0232.html Which I believe means inclusion of the patch should be accepted once it gets reviewer approval, no? Have other browser vendors implemented this feature or have shown their commitments to implement this feature? Or better yet, have we seen anyone using the element? I'd say it's still pre-mature to add the support to WebKit given the discussion taking place on this thread (particularly per Brendan's comment) and WHATWG. Furthermore, there is nothing that prevents authors from using main element today since the only difference will be whether it's recognized by AT and that prototype name will be HTMLMainElement once we support it. I would have been more supportive of the patch if it were adding some Web-content visible API but this is one feature authors can start using today without us explicitly supporting it. Given above points and that the patch is fairly small and self-contained, I don't see a harm in waiting another couple of weeks or months until standards discussion settles assuming that the main element doesn't become the longdesc of the next decade. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
My object is somewhat different. I think it's useful for the readability
use-case (and the other proposed solutions are mostly bad jokes), but it
doesn't strike me that this give you much default UI and doesn't plumb
through any new low-level capability.
In that vein, I wonder why it's not being proposed as an ARIA role instead?
On Tuesday, November 27, 2012, Ojan Vafai wrote:
As I said on the thread you link to, I don't think this element addresses
any real use-cases. I think people are far too likely to misuse this for it
to be useful for things like readability to use.
If Apple really wants this, I won't object, but my preference would be to
not implement this.
On Mon, Nov 26, 2012 at 2:01 PM, Steve Faulkner
faulkner.st...@gmail.comjavascript:_e({}, 'cvml',
'faulkner.st...@gmail.com');
wrote:
Hi all,
this is my first post to the list.
I have submitted a patch [1] to add main element support to webkit and
would appreciate your consideration.
the main element is defined here:
http://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html
current
status unofficial draft, CFC [2] to publish as a first working draft via
HTML WG ends today.
Rationale and use cases:
http://www.w3.org/html/wg/wiki/User:Sfaulkne/main-usecases#Introduction
details of data set and data analysis conducted during development of
feature:
http://lists.w3.org/Archives/Public/public-html/2012Oct/0109.html
There has been discussion and feedback provided on the WHATWG list [3]
and IRC and at TPAC 2012 HTML WG meeting.
I look forward to your comments!
[1] https://bugs.webkit.org/show_bug.cgi?id=103172
[2]
http://lists.w3.org/Archives/Public/public-html/2012Nov/thread.html#msg129
[3] threads start here:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/thread.html#msg55
--
with regards
Steve Faulkner
Technical Director - TPG
www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
http://www.paciellogroup.com/resources/wat-ie-about.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org javascript:_e({}, 'cvml',
'webkit-dev@lists.webkit.org');
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Nov 29, 2012, at 7:10 PM, Ryosuke Niwa rn...@webkit.org wrote: I don't see a harm in waiting another couple of weeks or months until standards discussion settles assuming that the main element doesn't become the longdesc of the next decade. Don't confuse the two. The argument over the @longdesc extension is not even close to unanimous even within the accessibility development circles. Major objections to @longdesc came from several of us working full-time on accessibility. The main element, in contrast, appears to have near unanimous support amongst the accessibility development community, and is a 1:1 semantic match with role=main which is being used on many major websites. I think we'll see quick author adoption of main once this patch ships. James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Thu, Nov 29, 2012 at 7:32 PM, James Craig jcr...@apple.com wrote: On Nov 29, 2012, at 7:10 PM, Ryosuke Niwa rn...@webkit.org wrote: I don't see a harm in waiting another couple of weeks or months until standards discussion settles assuming that the main element doesn't become the longdesc of the next decade. Don't confuse the two. The argument over the @longdesc extension is not even close to unanimous even within the accessibility development circles. Major objections to @longdesc came from several of us working full-time on accessibility. I was not intending to confuse the two. What I all meant to point out is that there still is an active debate. I mean just look at responses on this thread. There are people objecting to this feature. That’s a good indication that the feature is still premature. I’m not necessarily objecting to adding this feature to WebKit at some point. All I’m asking is to wait until standards discussion settles. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Thu, Nov 29, 2012 at 7:32 PM, James Craig jcr...@apple.com wrote: On Nov 29, 2012, at 7:10 PM, Ryosuke Niwa rn...@webkit.org wrote: I don't see a harm in waiting another couple of weeks or months until standards discussion settles assuming that the main element doesn't become the longdesc of the next decade. I’ll further clarify that I said assuming that the main element doesn't become the longdesc of the next decade in the hope that we don’t end up debating this matter for too long so that we can either accept the patch or reject it based on the community consensus. I was not implying that the main element is inherently controversial feature already. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: HTMLTemplateElement
On Wed, Nov 28, 2012 at 1:31 PM, Rafael Weinstein rafa...@chromium.orgwrote: Hello, WebKit! I plan to start landing the implementation of the HTMLTemplateElement (behind a compile flag). The spec is here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html A recent discussion on public-webapps explored the issue and considered alternative approaches, but ultimately converged back to the semantics described in the spec above. The spec has support from Microsoft. Google (spec authors) and Mozilla. How much support? Have they implemented? Deployed? What test suites are available? What is the W3C plan for adopting this feature in the official W3C HTML5.* spec track? The meta bug is here: https://bugs.webkit.org/show_bug.cgi?id=103547 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: HTMLTemplateElement
On Thu, Nov 29, 2012 at 8:55 PM, Glenn Adams gl...@skynav.com wrote: On Wed, Nov 28, 2012 at 1:31 PM, Rafael Weinstein rafa...@chromium.orgwrote: Hello, WebKit! I plan to start landing the implementation of the HTMLTemplateElement (behind a compile flag). The spec is here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html A recent discussion on public-webapps explored the issue and considered alternative approaches, but ultimately converged back to the semantics described in the spec above. The spec has support from Microsoft. Google (spec authors) and Mozilla. How much support? Have they implemented? Deployed? What test suites are available? What is the W3C plan for adopting this feature in the official W3C HTML5.* spec track? We don’t typically require test suites to be available prior to implementing it in WebKit or it be in the official HTML5 specification. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: HTMLTemplateElement
On Thu, Nov 29, 2012 at 10:00 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Nov 29, 2012 at 8:55 PM, Glenn Adams gl...@skynav.com wrote: On Wed, Nov 28, 2012 at 1:31 PM, Rafael Weinstein rafa...@chromium.orgwrote: Hello, WebKit! I plan to start landing the implementation of the HTMLTemplateElement (behind a compile flag). The spec is here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html A recent discussion on public-webapps explored the issue and considered alternative approaches, but ultimately converged back to the semantics described in the spec above. The spec has support from Microsoft. Google (spec authors) and Mozilla. How much support? Have they implemented? Deployed? What test suites are available? What is the W3C plan for adopting this feature in the official W3C HTML5.* spec track? We don’t typically require test suites to be available prior to implementing it in WebKit or it be in the official HTML5 specification. I didnt' suggest it was. However, if test suites are not available, then I would wonder about the maturity and or consensus status within the W3C arena. I ask because I'm curious about the maturity/stability of this feature. I also find it useful to apply a degree of caution to features that are coming from WHATWG if there is no counter-commitment to move those features forward in the official W3C REC track. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Nov 29, 2012, at 8:35 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Nov 29, 2012 at 7:32 PM, James Craig jcr...@apple.com wrote: On Nov 29, 2012, at 7:10 PM, Ryosuke Niwa rn...@webkit.org wrote: I don't see a harm in waiting another couple of weeks or months until standards discussion settles assuming that the main element doesn't become the longdesc of the next decade. Don't confuse the two. The argument over the @longdesc extension is not even close to unanimous even within the accessibility development circles. Major objections to @longdesc came from several of us working full-time on accessibility. I was not intending to confuse the two. What I all meant to point out is that there still is an active debate. I mean just look at responses on this thread. There are people objecting to this feature. That’s a good indication that the feature is still premature. I’m not necessarily objecting to adding this feature to WebKit at some point. All I’m asking is to wait until standards discussion settles. I think this thread does not show a clear consensus either way, at least at this time. I worry though, that more standards discussion will not resolve the impasses. The HTML WG has moved forward with its main element specification and that seems unlikely to change. The WHATWG has pretty clearly rejected the idea of the main element and that seems unlikely to change. I am not sure how we as a community should deal with an impasse where there is a split like this and little hope of resolving it. It seems there are precedents in both directions and folks judge on the merits (for example, the community clearly does not favor support for HTML+RDFa and its related API, but there is ongoing implementation work for Encrypted Media Extensions; both of these are html extensions pushed by the w3c but rejected by the whatwg). Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: HTMLTemplateElement
On Nov 29, 2012, at 9:23 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Nov 29, 2012 at 10:00 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Nov 29, 2012 at 8:55 PM, Glenn Adams gl...@skynav.com wrote: On Wed, Nov 28, 2012 at 1:31 PM, Rafael Weinstein rafa...@chromium.org wrote: Hello, WebKit! I plan to start landing the implementation of the HTMLTemplateElement (behind a compile flag). The spec is here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html A recent discussion on public-webapps explored the issue and considered alternative approaches, but ultimately converged back to the semantics described in the spec above. The spec has support from Microsoft. Google (spec authors) and Mozilla. How much support? Have they implemented? Deployed? What test suites are available? What is the W3C plan for adopting this feature in the official W3C HTML5.* spec track? We don’t typically require test suites to be available prior to implementing it in WebKit or it be in the official HTML5 specification. I didnt' suggest it was. However, if test suites are not available, then I would wonder about the maturity and or consensus status within the W3C arena. I ask because I'm curious about the maturity/stability of this feature. I also find it useful to apply a degree of caution to features that are coming from WHATWG if there is no counter-commitment to move those features forward in the official W3C REC track. template has a w3c spec proposal that has been discussed extensively in Web Apps WG. If there are explicit statements of support from Mozilla and.or Microsoft it might be good to cite those. I have sort of followed the discussions but can't speak to the maturity level here. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: HTMLTemplateElement
On Thu, Nov 29, 2012 at 9:23 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Nov 29, 2012 at 10:00 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Nov 29, 2012 at 8:55 PM, Glenn Adams gl...@skynav.com wrote: On Wed, Nov 28, 2012 at 1:31 PM, Rafael Weinstein rafa...@chromium.org wrote: Hello, WebKit! I plan to start landing the implementation of the HTMLTemplateElement (behind a compile flag). The spec is here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html A recent discussion on public-webapps explored the issue and considered alternative approaches, but ultimately converged back to the semantics described in the spec above. The spec has support from Microsoft. Google (spec authors) and Mozilla. How much support? Have they implemented? Deployed? What test suites are available? What is the W3C plan for adopting this feature in the official W3C HTML5.* spec track? We don’t typically require test suites to be available prior to implementing it in WebKit or it be in the official HTML5 specification. I didnt' suggest it was. However, if test suites are not available, then I would wonder about the maturity and or consensus status within the W3C arena. I ask because I'm curious about the maturity/stability of this feature. I also find it useful to apply a degree of caution to features that are coming from WHATWG if there is no counter-commitment to move those features forward in the official W3C REC track. Our intention is to move these this spec through the W3C REC process and update the implementation as the spec evolves. As Maciej says, there has already been a good deal of discussion about this spec in the WebApps working group. It's not clear to me whether it's more appropriate for the WebApps working group (where much if the other web components work is taking place) or the HTML working group (where HTML parsing is defined). I'm sure that's something we'll need to discuss with the chairs and the W3C team at the appropriate time. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Adding main element to WebCore
maciej wrote: The WHATWG has pretty clearly rejected the idea of the main element can you point to a clear rejection in any of the relevant threads on the WHATWG apart from hixies? I would suggest the WHATWG has general support for adding main, but I may not be understanding what is meant by a whatwg rejection in this case. regards SteveF On Nov 29, 2012, at 8:35 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Nov 29, 2012 at 7:32 PM, James Craig jcr...@apple.com wrote: On Nov 29, 2012, at 7:10 PM, Ryosuke Niwa rn...@webkit.org wrote: I don't see a harm in waiting another couple of weeks or months until standards discussion settles assuming that the main element doesn't become the longdesc of the next decade. Don't confuse the two. The argument over the @longdesc extension is not even close to unanimous even within the accessibility development circles. Major objections to @longdesc came from several of us working full-time on accessibility. I was not intending to confuse the two. What I all meant to point out is that there still is an active debate. I mean just look at responses on this thread. There are people objecting to this feature. That?s a good indication that the feature is still premature. I?m not necessarily objecting to adding this feature to WebKit at some point. All I?m asking is to wait until standards discussion settles. I think this thread does not show a clear consensus either way, at least at this time. I worry though, that more standards discussion will not resolve the impasses. The HTML WG has moved forward with its main element specification and that seems unlikely to change. The WHATWG has pretty clearly rejected the idea of the main element and that seems unlikely to change. I am not sure how we as a community should deal with an impasse where there is a split like this and little hope of resolving it. It seems there are precedents in both directions and folks judge on the merits (for example, the community clearly does not favor support for HTML+RDFa and its related API, but there is ongoing implementation work for Encrypted Media Extensions; both of these are html extensions pushed by the w3c but rejected by the whatwg). Regards, Maciej -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: HTMLTemplateElement
On Thu, Nov 29, 2012 at 9:55 PM, Adam Barth aba...@webkit.org wrote: On Thu, Nov 29, 2012 at 9:23 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Nov 29, 2012 at 10:00 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Nov 29, 2012 at 8:55 PM, Glenn Adams gl...@skynav.com wrote: On Wed, Nov 28, 2012 at 1:31 PM, Rafael Weinstein rafa...@chromium.org wrote: Hello, WebKit! I plan to start landing the implementation of the HTMLTemplateElement (behind a compile flag). The spec is here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html A recent discussion on public-webapps explored the issue and considered alternative approaches, but ultimately converged back to the semantics described in the spec above. The spec has support from Microsoft. Google (spec authors) and Mozilla. How much support? Have they implemented? Deployed? What test suites are available? What is the W3C plan for adopting this feature in the official W3C HTML5.* spec track? The spec is currently in the WebApps: http://www.w3.org/2008/webapps/wiki/PubStatus My assumption is that unless someone objects to it being there (rather than HTML), it will stay. Microsoft co-edited the spec, and made a public statement of support here: http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0336.html Mozilla indicated they are looking at implementing here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17930#c3 There is an test suite included in this bug which adds to the existing html5lib test suite, which can later be merged back to w3c. We don’t typically require test suites to be available prior to implementing it in WebKit or it be in the official HTML5 specification. I didnt' suggest it was. However, if test suites are not available, then I would wonder about the maturity and or consensus status within the W3C arena. I ask because I'm curious about the maturity/stability of this feature. I also find it useful to apply a degree of caution to features that are coming from WHATWG if there is no counter-commitment to move those features forward in the official W3C REC track. Our intention is to move these this spec through the W3C REC process and update the implementation as the spec evolves. As Maciej says, there has already been a good deal of discussion about this spec in the WebApps working group. It's not clear to me whether it's more appropriate for the WebApps working group (where much if the other web components work is taking place) or the HTML working group (where HTML parsing is defined). I'm sure that's something we'll need to discuss with the chairs and the W3C team at the appropriate time. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Nov 29, 2012, at 10:00 PM, Steve Faulkner faulkner.st...@gmail.com wrote: maciej wrote: The WHATWG has pretty clearly rejected the idea of the main element can you point to a clear rejection in any of the relevant threads on the WHATWG apart from hixies? I would suggest the WHATWG has general support for adding main, but I may not be understanding what is meant by a whatwg rejection in this case. I mean that by the whatwg process, if Hixie says no clearly and definitively, that is the decision. I say this not to judge, just to describe what it is. This does not of course mean that everyone who participates in the WHATWG agrees. The only thing I see as likely to change things in the whatwg is implementations appearing. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
Maciej Stachowiak m...@apple.com, 2012-11-29 21:48 -0800: The WHATWG has pretty clearly rejected the idea of the main element I don't think that assertion's true. Yeah, Hixie rejected it. And has consistently rejected every time we've had this discussion come up in WHATWG fora over the years; But I think among people active in the WHATWG over those same years, there have been more who support adding it than there are who clearly reject it. And that to me at least that still seems to be the state of things now. Simon Pieters, for example, is one who's expressed strong support: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0055.html And others like James Craig have said something along the lines of I think it seems like a reasonable idea: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0064.html And then there are of others active in the WHATWG who just haven't expressed an opinion on it either way. Anyway as I said, the discussion about it in the WHATWG has been coming up for years -- long before the HTML WG got around to noticing. The reason it stalled in those WHATWG discussions every time was not because of any clear consensus in the WHATWG to reject it ever emerged, but instead simply because Hixie rejected it each time and didn't spec anything out for it. I'm not stating a position on it here to say that Hixie is right or wrong about it. I'm just saying that it's not at all the case that there's strong consensus to reject it among the people who are most active in the WHATWG. and that seems unlikely to change. I am not sure how we as a community should deal with an impasse where there is a split like this and little hope of resolving it. As far as I can see, there is no split. If anything, the evidence seems to suggest there's more support for it in the WHATWG overall than there is strong opposition to it. And there are some who while not wholly supportive have said they don't feel strongly enough about it to block it; e.g., along the lines of the position Ojan expressed in his recent message here: http://lists.webkit.org/pipermail/webkit-dev/2012-November/023001.html All I meant to say is that I wouldn't fight to block this feature if another reviewer felt there was enough agreement to r+ the patch. --Mike -- Michael[tm] Smith http://people.w3.org/mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
Hi Maciej, thanks for the clarification. I would suggest that if, as in this case, Hixie rejects a feature without convincing the WHATWG community that the data, use cases etc do not support the introduction of a feature, then the WHATWG process is broken. regards SteveF On 30 November 2012 06:18, Maciej Stachowiak m...@apple.com wrote: On Nov 29, 2012, at 10:00 PM, Steve Faulkner faulkner.st...@gmail.com wrote: maciej wrote: The WHATWG has pretty clearly rejected the idea of the main element can you point to a clear rejection in any of the relevant threads on the WHATWG apart from hixies? I would suggest the WHATWG has general support for adding main, but I may not be understanding what is meant by a whatwg rejection in this case. I mean that by the whatwg process, if Hixie says no clearly and definitively, that is the decision. I say this not to judge, just to describe what it is. This does not of course mean that everyone who participates in the WHATWG agrees. The only thing I see as likely to change things in the whatwg is implementations appearing. Regards, Maciej -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
I think discussing the merits of the whatwg process is probably off topic for this list. - Maciej On Nov 29, 2012, at 10:32 PM, Steve Faulkner faulkner.st...@gmail.com wrote: Hi Maciej, thanks for the clarification. I would suggest that if, as in this case, Hixie rejects a feature without convincing the WHATWG community that the data, use cases etc do not support the introduction of a feature, then the WHATWG process is broken. regards SteveF On 30 November 2012 06:18, Maciej Stachowiak m...@apple.com wrote: On Nov 29, 2012, at 10:00 PM, Steve Faulkner faulkner.st...@gmail.com wrote: maciej wrote: The WHATWG has pretty clearly rejected the idea of the main element can you point to a clear rejection in any of the relevant threads on the WHATWG apart from hixies? I would suggest the WHATWG has general support for adding main, but I may not be understanding what is meant by a whatwg rejection in this case. I mean that by the whatwg process, if Hixie says no clearly and definitively, that is the decision. I say this not to judge, just to describe what it is. This does not of course mean that everyone who participates in the WHATWG agrees. The only thing I see as likely to change things in the whatwg is implementations appearing. Regards, Maciej -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
Maciej Stachowiak m...@apple.com, 2012-11-29 22:18 -0800: I mean that by the whatwg process, if Hixie says no clearly and definitively, that is the decision. Yeah, agreed. But we have lots of other cases where Hixie has either outright said No or has just simply not specced out something. And in those cases somebody else had specced something out and sometimes even implemented it experimentally and then we've seen it get incorporated back into the HTML spec later or become a deliverable of a W3C working group. And as Hixie will tell you himself, there are plenty of things that have eventually made their way into the HTML spec despite Hixie personally thinking they were bad ideas. I say this not to judge, just to describe what it is. This does not of course mean that everyone who participates in the WHATWG agrees. The only thing I see as likely to change things in the whatwg is implementations appearing. Yeah, and Hixie has said as much himself: http://lists.w3.org/Archives/Public/www-archive/2012Nov/0041.html as far as main goes, despite it being a bad idea, there does seem to be some support for it amongst implementors. So your best move, if you think it's a good idea, would be to convince them to implement it. That would be new data which would almost immediately cause the spec to have it added, regardless of how good an idea it is. I think that's the spirit in which Steve took time to contribute code for this, and to start the discussion about it here. --Mike -- Michael[tm] Smith http://people.w3.org/mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Fwd: Adding main element to WebCore
Brendan Eich bren...@mozilla.org, 2012-11-27 20:39 -0800: I'm stunned that people are arguing this on webkit-dev. Just FYI, Mozillians with whom I have spoken generally agree that main does not meet the high bar required to add a new element to HTML. Shopping a patch to implementors, to get something into a standard spec by asserting de-facto status based on the patch(es) landing, is bad form. Back to the whatwg list! I know you've since qualified a bit some of what you said in this earlier message, and it's probably also bad form for me to repeat something I just said in another message in this thread, but for the record I want to note that I think part of the context for Steve having taken time to write up his patch and bring the discussion here is an earlier discussion he had with Hixie, in which Hixie said: as far as main goes, despite it being a bad idea, there does seem to be some support for it amongst implementors. So your best move, if you think it's a good idea, would be to convince them to implement it. That would be new data which would almost immediately cause the spec to have it added, regardless of how good an idea it is. http://lists.w3.org/Archives/Public/www-archive/2012Nov/0041.html -- Michael[tm] Smith http://people.w3.org/mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On 30 November 2012 06:46, Michael[tm] Smith m...@w3.org wrote: I think that's the spirit in which Steve took time to contribute code for this, and to start the discussion about it here. Yes, I was motivated by what Maciej stated on the whatwg list [1]: Overall, I would not fall on my sword to get the main element into WebKit but I would not reject a patch to add it either, assuming a sufficiently good spec exists for it somewhere. [1] http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0104.html -- with regards SteveF ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: HTMLTemplateElement
On Thu, Nov 29, 2012 at 11:05 PM, Rafael Weinstein rafa...@chromium.orgwrote: On Thu, Nov 29, 2012 at 9:55 PM, Adam Barth aba...@webkit.org wrote: On Thu, Nov 29, 2012 at 9:23 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Nov 29, 2012 at 10:00 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Nov 29, 2012 at 8:55 PM, Glenn Adams gl...@skynav.com wrote: On Wed, Nov 28, 2012 at 1:31 PM, Rafael Weinstein rafa...@chromium.org wrote: Hello, WebKit! I plan to start landing the implementation of the HTMLTemplateElement (behind a compile flag). The spec is here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html A recent discussion on public-webapps explored the issue and considered alternative approaches, but ultimately converged back to the semantics described in the spec above. The spec has support from Microsoft. Google (spec authors) and Mozilla. How much support? Have they implemented? Deployed? What test suites are available? What is the W3C plan for adopting this feature in the official W3C HTML5.* spec track? The spec is currently in the WebApps: http://www.w3.org/2008/webapps/wiki/PubStatus My assumption is that unless someone objects to it being there (rather than HTML), it will stay. Microsoft co-edited the spec, and made a public statement of support here: http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0336.html Mozilla indicated they are looking at implementing here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17930#c3 There is an test suite included in this bug which adds to the existing html5lib test suite, which can later be merged back to w3c. Thanks for the additional detail. It looks like this has sufficient support to move forward. We might want to determine whether or not any vendor specific prefixing is needed before moving into wider exposure, but I trust that reviewers will take this into account. We don’t typically require test suites to be available prior to implementing it in WebKit or it be in the official HTML5 specification. I didnt' suggest it was. However, if test suites are not available, then I would wonder about the maturity and or consensus status within the W3C arena. I ask because I'm curious about the maturity/stability of this feature. I also find it useful to apply a degree of caution to features that are coming from WHATWG if there is no counter-commitment to move those features forward in the official W3C REC track. Our intention is to move these this spec through the W3C REC process and update the implementation as the spec evolves. As Maciej says, there has already been a good deal of discussion about this spec in the WebApps working group. It's not clear to me whether it's more appropriate for the WebApps working group (where much if the other web components work is taking place) or the HTML working group (where HTML parsing is defined). I'm sure that's something we'll need to discuss with the chairs and the W3C team at the appropriate time. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Nov 29, 2012, at 10:46 PM, Michael[tm] Smith m...@w3.org wrote: The only thing I see as likely to change things in the whatwg is implementations appearing. Yeah, and Hixie has said as much himself: http://lists.w3.org/Archives/Public/www-archive/2012Nov/0041.html as far as main goes, despite it being a bad idea, there does seem to be some support for it amongst implementors. So your best move, if you think it's a good idea, would be to convince them to implement it. That would be new data which would almost immediately cause the spec to have it added, regardless of how good an idea it is. I think that's the spirit in which Steve took time to contribute code for this, and to start the discussion about it here. Yes, and I commend Steve for taking the time and effort to do that. I think it was a good thing. I am not sure the WebKit community as a whole will buy into main at this time but it was super valuable to have the opportunity to discuss it, regardless of the short-term outcome. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On 30 November 2012 06:38, Maciej Stachowiak m...@apple.com wrote: I think discussing the merits of the whatwg process is probably off topic for this list. agreed, I am just trying to stop process getting in the way of adding a feature (notedly a minor one) to HTML which will benefit users with disabilities. regards SteveF ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
Ryosuke Niwa rn...@webkit.org, 2012-11-29 19:10 -0800: Have other browser vendors implemented this feature or have shown their commitments to implement this feature? Or better yet, have we seen anyone using the element? No, nobody has implemented main yet. But we all know there are gazillions of existing Web pages marked up with div class=main and div class=content. And going forward, developers everywhere every minute of every day are marking up new content with those or some other explicit indicators of what the main content of the page is. And they'll keep doing that. The difference this would bring is that instead of them continuing to be limited just to ad-hoc ways to do that, we'd have a standard way they could could mark it up. So I think the practical view that's driving support for main is very much in keeping with the same Pave the Cowpaths design principle that's among the set of principles that've been driving a lot of the work we've all been doing together on standards for the platform for the last 8+ years now (when the work started to become refocused in the right direction) -- http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new. --Mike -- Michael[tm] Smith http://people.w3.org/mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
