W3C home > Mailing lists > Public > www-archive@w3.org > September 2014

Re: W3C Proposed Recommendation: HTML5

From: Robin Berjon <robin@w3.org>
Date: Mon, 22 Sep 2014 17:02:15 +0200
Message-ID: <542039F7.6040507@w3.org>
To: Anne van Kesteren <annevk@annevk.nl>
CC: Karl Dubost <kdubost@mozilla.com>, Boris Zbarsky <bzbarsky@mit.edu>, "L. David Baron" <dbaron@mozilla.com>, www-archive <www-archive@w3.org>
On 22/09/2014 16:31 , Anne van Kesteren wrote:
> On Mon, Sep 22, 2014 at 4:25 PM, Robin Berjon <robin@w3.org> wrote:
>> On 22/09/2014 16:15 , Anne van Kesteren wrote:
>>> Although DOM and XMLHttpRequest have a two-way dependency with
>>> HTML, effectively making them just another page that happens to be
>>> maintained by someone else.
>> I don't think that two-way dependencies are an issue. It's actually a fairly
>> expected feature of systems of any complexity.
> Ask the Blink team. A two-way dependency between modules makes it
> effectively the same module as you cannot update one without the
> other.
> Think about it, if you imported Fetch as a module. Would you want that
> to drag in XML, HTML, and DOM as well? At that point you failed to
> modularize.

And the answer is, of course, "it depends".

If you're talking about library-like modularity then sure enough it's a 
problem. For instance if there were a Node library that did fetch "like 
a browser" I'd really want to use it, and I'd be happier if it didn't 
also load up a complete implementation of HTML. But if you're talking 
about editorial modularity then I reckon you can live with well-defined 
interlinking points.

Also, I am somewhat reluctant to bandy about words like "refactoring" 
but cutting things up into smaller pieces can help with the former. 
Having "HTML <-> Fetch" isn't the same as "img -> Fetch -> FormData" 
(making this up, but you get the idea).

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Monday, 22 September 2014 15:02:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:44:33 UTC