Re: [webcomponents] HTML Imports

To be fair though Web Components are bleeding edge and the vast
majority of developers have had no interaction with them at all.
I work in a company that should see huge benefits from Web Components
as we build large scale browser applications and not one developer has
had the time to investigate Web Components properly.

I have even heard our developers say that Web Components are only for
small widgets like buttons and aren't designed for anything large
scale, basically a glorified "button" element.

People are busy and have jobs to do, I'd love to provide good feedback
on Web Components but time is a constraint.

I would say though that I get the feeling that Web Components seems a
specification that seems really pushed/rushed and I worry that might
lead to some poor design decisions whose side effects will be felt by
developers in the future.

Are we sure #include is what the web wants/needs?

On Wed, Dec 4, 2013 at 4:02 AM, Eric Bidelman <ericbidelman@google.com> wrote:
>
>
>
> On Tue, Dec 3, 2013 at 7:03 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>>
>> On Oct 7, 2013, at 12:24 PM, Rafael Weinstein <rafaelw@google.com> wrote:
>>
>> On Mon, Oct 7, 2013 at 3:24 AM, James Graham <james@hoppipolla.co.uk>
>> wrote:
>>>
>>> On 06/10/13 17:25, Dimitri Glazkov wrote:
>>>
>>>>     And, if the script is executed against the global/window object of
>>>>     the main document, can and should you be able to access the imported
>>>>     document?
>>>>
>>>>
>>>> You can and you should. HTML Imports are effectively #include for the
>>>> Web.
>>>
>>>
>>> Yes, that sounds like a good description of the problem :) It is rather
>>> noticable that no one making programming languages today replicates the
>>> #include mechanism, and I think html-imports has some of the same design
>>> flaws that makes #include unpopular.
>>>
>>>
>>> I think authors will find it very hard to write code in an environment
>>> where simple functions like document.getElementById don't actually work on
>>> the document containing the script, but on some other document that
>>>
>>> they can't see. It also seems that the design requires you to be super
>>> careful about having side effects; if the author happens to have a
>>> non-idempotent action in a document that is imported, then things will break
>>> in the relatively
>>>
>>> uncommon case where a single document is imported more than once.
>>
>>
>> We have an orthogonal mechanism for preventing side-effects: The HTML
>> Template Element. Imports do not prevent side-effects implicitly. This is
>> Good. Authors have control over the semantics they need. Want to include
>> some DOM -- use imports, need some fragment of that to not have side effects
>> -- put it in a <template>.
>>
>>
>> I don't think template element solves that problem if we're talking about
>> scripts that need to run as soon as the document is imported.
>>
>>
>> On Oct 9, 2013, at 10:42 AM, Scott Miles <sjmiles@google.com> wrote:
>>
>> On Mon, Oct 7, 2013 at 3:24 AM, James Graham <james@hoppipolla.co.uk>
>> wrote:
>>>
>>> On 06/10/13 17:25, Dimitri Glazkov wrote:
>>>
>>>>     And, if the script is executed against the global/window object of
>>>>     the main document, can and should you be able to access the imported
>>>>     document?
>>>>
>>>>
>>>> You can and you should. HTML Imports are effectively #include for the
>>>> Web.
>>>
>>>
>>> Yes, that sounds like a good description of the problem :) It is rather
>>> noticable that no one making programming languages today replicates the
>>> #include mechanism, and I think html-imports has some of the same design
>>> flaws that makes #include unpopular.
>>>
>>> I think authors will find it very hard to write code in an environment
>>> where simple functions like document.getElementById don't actually work on
>>> the document containing the script, but on some other document that they
>>> can't see.
>>
>>
>> It's true we are introducing something new, but this actually one of The
>> Good Parts. Imports are not the main document, they are satellite to the
>> main document. The main document maintains primacy, but your imports can act
>> on it. So far, we haven't really had any problems with developers on this
>> point.
>>
>>
>> We should be asking this question to an average Web developer who has
>> never heard of HTML imports before.
>
>
> I speak with web developers on a regular basis. Most are agreeable with
> distinction and generally positive about the possibilities it opens up.
>
> http://robdodson.me/blog/2013/08/20/exploring-html-imports/
>
>>
>>
>>
>>> It also seems that the design requires you to be super careful about
>>> having side effects; if the author happens to have a non-idempotent action
>>> in a document that is imported, then things will break in the relatively
>>> uncommon case where a single document is imported more than once.
>>
>>
>> Can you give an example of a non-idempotent, potentially breaking action?
>>
>>
>> e.g. defining a global variable.
>>
>>> Overall it feels like html imports has been designed as an over general
>>> mechanism to address certain narrow use cases and, in so doing, has handed
>>> authors a footgun.
>>
>>
>> I guess I would instead suggest that generality of HTML Imports is due to
>> the group attempting to find a virtuous primitive, instead of a special
>> case.
>>
>> For just one issue, look how much HTML becomes embedded in strings, or
>> hidden as comments, or other crazy hacks. We can import (relocatable!) CSS
>> and JS, why can we not import our most basic content?
>>
>>
>> We can address that problem without executing scripts in the host
>> document.  e.g.  If I'm importing foo.html, it wouldn't be the end of the
>> world for all objects defined in foo.html to be under "window.foo".  We can
>> let the imported document access the host document via ownerDocument or
>> whatever to address the other use case but let's not introduce another
>> footgun.
>>
>> - R. Niwa
>>
>

Received on Wednesday, 4 December 2013 09:21:58 UTC