Re: [webcomponents] HTML Parsing and the element

[Adam Barth]

On Wed, Apr 4, 2012 at 12:12 PM, Rafael Weinstein  wrote:
> On Mon, Apr 2, 2012 at 3:21 PM, Dimitri Glazkov  wrote:
>> On Wed, Feb 8, 2012 at 11:25 PM, Henri Sivonen  wrote:
>>> On Thu, Feb 9, 2012 at 12:00 AM, Dimitri Glazkov  
>>> 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
>>  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=128579&action=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 
>> 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 
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
>> stead

[Bug 16639] New: tr hrt hrt rth rt trr tr rt

[bugzilla]

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

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16639

Art Barstow  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)

[Arthur Barstow]

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 
 addresses that 
action.  

(I think TAG has related action Action-344).

-AB

Begin forwarded message:

> From: ext Web Applications Working Group Issue Tracker 
> Date: April 28, 2011 10:15:13 AM EDT
> To: 
> 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 
> 
> 
> 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?

[Aryeh Gregor]

On Wed, Apr 4, 2012 at 10:07 PM, Ojan Vafai  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

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16449

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Anne  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

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16451

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Anne  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

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=8406

Travis Leithead [MSFT]  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #17 from Travis Leithead [MSFT]  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.