[Bug 18669] Switch from is= to <tag if a decision has been reached among implementers

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

--- Comment #29 from brian kardell <bkardell@gmail.com> ---
It _seems_ as if Hixie and Jonas suggest that if we changed <x-foo where the
base of foo (imagine it is select) is defined elsewhere to <select/foo (where
select has to match the related extends value essentially) then we are pretty
close otherwise because for some reason the parser in browsers will currently
parse that as <select foo and therefore provide cover for most of the concerns
that Ian had and still kinda "looks" like a tag - the major diff being "/"
instead of "-".

If that is not the case, please let me know - but assuming that it is, here are
some additional thoughts/observations/concerns/questions... Please let me know
where I am on/off in your opinions...




* Most of the examples we've been discussing are kind of incomplete.  If we are
trying to take advantage of the unchanged parser, we'd really have to include
the "x-" anyway, right? else we are adding an attribute in the main namespace
and that could go very badly.  Thus, we're not really talking about
<select/map>, we are talking about <select/x-map>.  Not that that matters in a
substantial way I just want to be clear.

* I'd also like to note that we are not illustrating the close tag... Since we
are taking advantage of the parser quirk, this means that
<select/x-map>...</select/x-map>  parses (we tried it) - but so is
<select/x-map>...</select>.  So which would those proposing advocate is taught? 

    * The former is actually really hard for anything but the html parser to
parse (including humans) and given Hixie's concerns about microparsers and
things in search engines, etc. I think he might like to take note that all of
the tools we (Daniel and I) played with in considering how to make this work
had problems:  Syntax highlighters screwed up, auto-completion/correction doing
whacky things, etc.

    * The later isn't _as bad_ but still problematic in numerous ways. 
Visually it is unlike anything else in html today - both in the sense that
authors (and many tools) see "/" in a tag and think "close" and the start and
end "tag" don't appear to match.  

* In order to do anything remotely useful with fallback content, in a legacy
browser at least, you would have to understand what is going on under the
covers... you'd have to get that qsa or css would require "select[x-foo]", for
example.

---- all of the above makes me feel like hixie/jonas et-all are just confusing
things by adding a slash at all since "<select x-map" is identical, fully
equivalent, vanilla html that doesn't suffer from the problems above.  It is,
however, less good in numerous ways than "<select is=map" or "<select is=x-map"
because that always has a known attribute which has a ton of advantages in
terms of simplicity and what we can do with it.


Are we all on the same page thus far?


If so, the advantages (feel free to add/comment):

  - If done perfectly, with simple cases it will yield something
expectable/predictable and maybe even semi-functional in legacy UA (aside: 
that might not be what the author actually wants - I know I sometimes
wouldn't).


And the disadvantages:

  - Many (maybe most) of them will be built on meaningless semantic elements
like div or span (again, I will point you to google io's examples where complex
inputs are build on divs, not other inputs and ask that someone please explain
how to do those otherwise and why they would expect page authors to be smarter
than the presenters).  As Daniel mentioned: at this point they may simply opt
to use "x" since an unknown element is technically about as good.

  - Maybe most importantly to me:  This doesn't help the problem for legacy UAs
in any way that Web Components can and will be nested/composed.  Composition is
one of the most attractive features of Web Components to many authors who have
long argued that it has been missing for a long time and you can bet it will be
used.

  - This adds the complexity of having to know significantly more information
in order to use a component and considerably more verbose input.  If the types
don't agree in page and in definition, upgrade will fail - this also argues to
me at least that authors will have a strong desire to subvert this limitation
by going with a standard "x" or something.



Is there any reason that someone could not achieve fallback in hixie's map
example by simply developing their component so that the input was allowed to
have the outer element?  In other words - if you wanted fallback - you could
just:

<x-map>
   <select name="country">
       <option>FR</option>
       <option>UK</option>
       <option>US</option>
   </select>
</x-map>

Legacy browsers will show the x-map and presumably new system would upgrade on
parse too... If so - what's the problem that the <select/map solves?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 10 January 2013 16:44:07 UTC