[Webkit-unassigned] [Bug 47264] Introduce the device element as an experimental feature

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jan 28 11:42:08 PST 2011


https://bugs.webkit.org/show_bug.cgi?id=47264


Adam Barth <abarth at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |abarth at webkit.org




--- Comment #8 from Adam Barth <abarth at webkit.org>  2011-01-28 11:42:07 PST ---
(In reply to comment #7)
> (In reply to comment #6)
> 
> > HTML parsing should not be conditional on which features are enabled.  If this line of could should be here, it should be here unconditionally and we should have parser test that demonstrates this change.
> 
> Is it possible to remove the end tag requirement without touching the parser code, like you could with the old parser? I guess we still want the device element to be feature guarded?

Does the HTML5 specification mention the device element when describing the parsing algorithm?  Our parsing algorithm matches the HTML5 spec exactly.  If the HTML5 parsing algorithm says the device element should be in this list, then it should be there unconditionally.  If it doesn't say that the device element should be in this list, then it should not be there unconditionally.  In no case should HTML parsing depend on which features are enabled.

> > #if 0 ?
> 
>  38 #if 0
>  39 #else
>  40 #define StreamDeviceManagerPrivateClassName NullStreamDeviceManagerPrivate
>  41 #endif 
> 
> The "if 0" was intended has a hint to where platform specific code should go. That line is overwritten when you apply the GTK-specific patch (see https://bugs.webkit.org/show_bug.cgi?id=53264). In this case it forces the usage of the fallback class NullStreamDeviceManagerPrivate. Perhaps it would be better to just use a single #define.

That's fine, but we shouldn't have "#if 0" in the code.  IMHO, a FIXME comment is a better way of indicating that some port-specific logics goes here.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list