Re: [webcomponents] HTML Parsing and the template element
On Wed, Apr 4, 2012 at 12:12 PM, Rafael Weinstein rafa...@google.com wrote: On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Feb 8, 2012 at 11:25 PM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Feb 9, 2012 at 12:00 AM, Dimitri Glazkov dglaz...@chromium.org wrote: == IDEA 1: Keep template contents parsing in the tokenizer == Not this! Here's why: Making something look like markup but then not tokenizing it as markup is confusing. The confusion leads to authors not having a clear mental model of what's going on and where stuff ends. Trying to make things just work for authors leads to even more confusing here be dragons solutions. Check out http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state Making something that looks like markup but isn't tokenized as markup also makes the delta between HTML and XHTML greater. Some people may be ready to throw XHTML under the bus completely at this point, but this also goes back to the confusion point. Apart from namespaces, the mental model you can teach for XML is remarkably sane. Whenever HTML deviates from it, it's a complication in the understandability of HTML. Also, multi-level parsing is in principle bad for perf. (How bad really? Dunno.) I *really* don't want to end up writing a single-pass parser that has to be black-box indishtinguishable from something that's defined as a multi-pass parser. (There might be a longer essay about how this sucks in the public-html archives, since the SVG WG proposed something like this at one point, too.) == IDEA 2: Just tweak insertion modes == I think a DWIM insertion mode that switches to another mode and reprocesses the token upon the first start tag token *without* trying to return to the DWIM insertion mode when the matching end tag is seen for the start tag that switched away from the DWIM mode is something that might be worth pursuing. If we do it, I think we should make it work for a fragment parsing API that doesn't require context beyound assuming HTML, too. (I think we shouldn't try to take the DWIM so far that a contextless API would try to guess HTML vs. SVG vs. MathML.) Just to connect the threads. A few weeks back, I posted an update about the HTML Templates spec: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1171.html Perhaps lost among other updates was the fact that I've gotten the first draft of HTML Templates spec out: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html The draft is roughly two parts: motivation for the spec and deltas to HTML specification to allow serialization and parsing of the template element. To be honest, after finishing the draft, I wondered if we should just merge the whole thing into the HTML specification. As a warm-up exercise for the draft, I first implemented the changes to tree construction algorithm here in WebKit (https://bugs.webkit.org/show_bug.cgi?id=78734). The patch (https://bugs.webkit.org/attachment.cgi?id=128579action=review) includes new parsing tests, and should be fairly intuitive to read to those familiar with the test format. The interesting bit here is that all parser changes are additive: we are only adding what effectively are extensions points -- well, that and a new contextless parsing mode for when inside of the template tag. I think the task previously was to show how dramatic the changes to the parser would need to be. Talking to Dimitri, it sounds to me like they turned out to be less open-heart-surgery and more quick outpatient procedure. Adam, Hixie, Henri, how do you guys feel about the invasiveness of the parser changes that Dimitri has turned out here? If you're going to change the parser when adding the template element, what's in that spec looks fairly reasonable to me. Hixie and Henri have spent more time designing the algorithm that I have (Eric and I just implemented it), so they might have a different perspective. Adam The violation of the Degrade Gracefully principle and tearing the parser spec open right when everybody converged on the spec worry me, though. I'm still hoping for a design that doesn't require parser changes at all and that doesn't blow up in legacy browsers (even better if the results in legacy browsers were sane enough to serve as input for a polyfill). I agree with your concern. It's bugging me too -- that's why I am not being an arrogant jerk yelling at people and trying to shove this through. In general, it's difficult to justify making changes to anything that's stable -- especially considering how long and painful the road to getting stable was. However, folks like Yehuda, Erik, and Rafael spent years tackling this problem, and I tend to trust their steady hand... hands? I don't think there's an option to degrade gracefully here. My personal feeling is that even if it's years
[Bug 16639] New: tr hrt hrt rth rt trr tr rt
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16639 Summary: tr hrt hrt rth rt trr tr rt Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Storage (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: public-webapps-bugzi...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/webstorage/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: tr hrt hrt rth rt trr tr rt Posted from: 88.146.176.146 User agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.142 Safari/535.19 -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 16639] tr hrt hrt rth rt trr tr rt
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16639 Art Barstow art.bars...@nokia.com changed: What|Removed |Added Status|NEW |RESOLVED CC||art.bars...@nokia.com Resolution||INVALID -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Fwd: ACTION-623: Notify TAG when a Last Call Working Draft of CORS or UMP is published (Web Applications Working Group)
Hi Noah - I have WebApps Action-623 to notify the TAG when CORS LC is published and Brad Hill's April 2 email to the TAG http://lists.w3.org/Archives/Public/www-tag/2012Apr/0042.html addresses that action. (I think TAG has related action Action-344). -AB Begin forwarded message: From: ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Date: April 28, 2011 10:15:13 AM EDT To: art.bars...@nokia.com Subject: ACTION-623: Notify TAG when a Last Call Working Draft of CORS or UMP is published (Web Applications Working Group) Reply-To: Web Applications Working Group WG public-webapps@w3.org ACTION-623: Notify TAG when a Last Call Working Draft of CORS or UMP is published (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/623 On: Arthur Barstow Due: 2011-05-05 Product: CORS If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/7672#settings
Re: [editing] input event should have a data property WAS: [D3E] Where did textInput go?
On Wed, Apr 4, 2012 at 10:07 PM, Ojan Vafai o...@chromium.org wrote: The original proposal to drop textInput included that beforeInput/input would have a data property of the plain text being inserted. Aryeh, how does that sound to you? Maybe the property should be called 'text'? 'data' is probably too generic. Sounds reasonable. Per spec, the editing variant of these events has .command and .value. I think .text is a good name for the plaintext version. It should just have the value that the input/textarea would have if the beforeinput event isn't canceled.
[Bug 16449] requestFullScreen() terminates at the wrong place
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16449 Anne ann...@opera.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Anne ann...@opera.com 2012-04-05 13:56:15 UTC --- http://dvcs.w3.org/hg/fullscreen/rev/2d0bfb08fab5 -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 16451] Clarify the order of the documents
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16451 Anne ann...@opera.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Anne ann...@opera.com 2012-04-05 13:59:12 UTC --- Correct. http://dvcs.w3.org/hg/fullscreen/rev/8d4e36bba490 -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 8406] Stricter Specifications on Mouse Events Specifically primary, auxillary, and secondary default actions
https://www.w3.org/Bugs/Public/show_bug.cgi?id=8406 Travis Leithead [MSFT] tra...@microsoft.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #17 from Travis Leithead [MSFT] tra...@microsoft.com 2012-04-05 23:49:26 UTC --- (In reply to comment #16) Someone brought up some confusion in the buttons member for MouseEvent. This is regarding the behavior of MouseEvent with multiple devices. Not sure if it's possible, but could you explicitly state that the MouseEvent buttons property represents the binary ORed result of all mouse device buttons. As an example if a person have both a laptop trackpad and a USB mouse if they hold both primary mouse buttons and release one the bit for the primary mouse button will still be set. I don't think that I'll note this in the spec. Here's why: Most (all?) operating systems that incorporate a mouse-driven pointing device, have only a single mouse input stack. Even if you plug in two mice or use a mouse + trackpad, as in your example, the underlying operating system is going to merge these inputs into one stack as best it can. For example, when moving each of these mice, you'll notice that each mouse does not maintain it's original position on screen relative to the last position it was moved to. Rather, movements of each mouse are relative to the current pointer position because their inputs are being merged. When using the mouse buttons, a similar merging will occur. This technique (by the way) will likely break most web-page-based state machines for tracking the mouse... If you press down on the primary mouse button of one device the OS will disptch a mousedown event to the system. Then if you press down on the primary mouse button of another device, the operating system will simply blindly (unless a specific OS handles this scenario better) dispatch another mousedown event! The button state that is reported by the DOM event in these cases is pretty dependent on how the OS exposes this information. When you release one of these buttons, my guess (not having two mice to check against on my windows-based box) is that the mouse-up event and related button are fed into the mouse state machine, and will report that no buttons are now pressed even though you're still holding down the other mouse button! These type of scenarios are much better suited for multi-point input, such as touch events, which have a different programming pattern in general. In such scenarios, web developers will know to _expect_ simultaneous input -- happily our fingers don't have buttons on them :-) I'm resolving as Fixed to avoid confusing this re-activation for a different issue with the resolution of the original issue. Please file a new bug if you have further feedback or issues with the spec :) -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
